# Gosign – Full Site Content
# Generated: 2026-07-09T14:24:09.230Z
# 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>

<!-- 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</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. 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>8. 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>9. 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>10. 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>11. 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>12. 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>13. 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>14. 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>15. 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>16. 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>17. 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 - tudo pertence a você</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
============================================================

--- 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.

Quellcode, Prompts, Regelwerke und Decision-Records gehen mit Repository-Übergabe vertraglich 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/).

--- 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. 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>8. 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>9. 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>10. 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>11. 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>12. 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>13. 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;14 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>14. 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>15. 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>16. 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>17. 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>18. 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>
</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>
</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>

<!-- 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</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 - alles gehört Ihnen</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>
<