# Gosign – Full Site Content
# Generated: 2026-07-28T04:20:32.250Z
# Enterprise AI Infrastructure & Agent Engineering Company
# https://www.gosign.de
============================================================
LANGUAGE: BR
============================================================
--- Agência Digital Hamburgo | Web, IA, TYPO3 ---
> Gosign é uma agência digital de Hamburgo para desenvolvimento web, integração de IA e TYPO3. 25 anos de experiência. Foco B2B.
O que é a Gosign?
A Gosign é uma agência digital de Hamburgo com 25 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.
Por que a Gosign?
Porque nós não construímos apenas sites - construímos infraestrutura digital. Três áreas de atuação, uma equipe:
Desenvolvimento web & CMS
Sites que performam. Tecnicamente e comercialmente. TYPO3, WordPress, Astro, arquiteturas Headless. Da concepção ao lançamento, de 10 páginas a 10.000. A Gosign analisou mais de 800 extensions TYPO3 e desenvolve projetos Enterprise CMS há mais de duas décadas.
Integração de IA para empresas
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.
Especialização em TYPO3
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.
Vamos conversar sobre o seu projeto - 30 minutos, gratuito.
Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.
25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA
O que diferencia a Gosign de outras agências digitais
Critério
Agência típica
Gosign
Profundidade CMS
WordPress básico
TYPO3 Enterprise + WordPress + Headless
Competência em IA
Prompts de ChatGPT
Infraestruturas de IA próprias, hospedagem de modelos
Velocidade de desenvolvimento
Tradicional
Acelerado por IA: 60 a 80% mais rápido
Foco setorial
Tudo para todos
B2B, empresas de médio porte, universidades, setor público
Segurança
Hospedagem padrão
Infraestruturas compatíveis com CERT.br, monitoramento de segurança
Localização
Remoto/Global
Hamburgo, hub europeu, atendimento personalizado
Setores
A Gosign trabalha para empresas que levam infraestrutura digital a sério:
Indústria & engenharia
Sites B2B com configuradores de produto, portais de distribuidores, documentação técnica
Automotivo
Portais de marca, redes de concessionárias, showrooms digitais
Saúde & farmacêutico
Sites em conformidade regulatória, portais de pacientes
Educação & universidades
SSO com Shibboleth, buscadores de cursos, sites acessíveis
Associações & setor público
Gestão de membros, portais multilíngues, acessibilidade
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.
--- 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 como agência WordPress?
A Gosign é uma agência WordPress de Hamburgo com 25 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.
Por que a Gosign e não uma agência WordPress comum?
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.
Serviços WordPress
Desenvolvimento de tema personalizado
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.
Desenvolvimento de plugins & customização
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%.
WooCommerce & e-commerce
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.
Manutenção & segurança WordPress
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.
Migração para WordPress
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.
Conversar sobre seu projeto WordPress - 30 minutos, gratuito.
Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.
25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA
Desenvolvimento WordPress acelerado por IA: 70% mais rápido
Tarefa
Tradicional
Com IA
Economia
Tema personalizado (10 templates)
3 a 4 semanas
1 a 1,5 semana
65%
Plugin personalizado
2 a 3 semanas
4 a 6 dias
70%
Setup loja WooCommerce
2 a 3 semanas
5 a 7 dias
65%
Migração de conteúdo (500 páginas)
2 semanas
3 dias
80%
Auditoria de segurança
3 dias
1 dia
70%
WordPress vs. TYPO3 vs. Headless: consultoria honesta
Critério
WordPress
TYPO3
Headless (Astro, Next.js)
Foco em conteúdo
Ideal
Bom
Mais complexo
Permissões enterprise
Limitado
Granular
Custom
E-commerce
WooCommerce
aimeos
Shopify API
Performance
Depende dos plugins
Necessita cache
Estático = rápido
Facilidade para editores
Excelente
Bom
Limitado
Recomendação Gosign
Sites de conteúdo, blogs, PMEs
Enterprise, universidades
Performance crítica
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.
--- 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.
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.
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.
Responsabilidade por links
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.
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.
Direitos autorais
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.
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.
Não estamos obrigados nem dispostos a participar em procedimentos de resolução de litígios perante uma comissão de arbitragem de consumidores.
Aviso de marcas registradas
SAP, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform e SAP Joule são marcas registradas ou marcas da SAP SE, Walldorf, Alemanha.
Microsoft, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory e Microsoft Graph são marcas registradas ou marcas da Microsoft Corporation, Redmond, EUA.
TOTVS é uma marca registrada da TOTVS S.A., São Paulo, Brasil.
Workday é uma marca registrada da Workday, Inc., Pleasanton, EUA.
Personio é uma marca da Personio SE & Co. KG, Munique, Alemanha.
Google e Google Calendar são marcas da Google LLC, Mountain View, EUA.
Todos os outros nomes de produtos e empresas mencionados são marcas ou marcas registradas de seus respectivos proprietários.
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.
--- 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 é acessibilidade digital e por que existe essa obrigação?
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.
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.
Para as empresas, isso significa: acessibilidade não é mais uma gentileza voluntária, mas uma obrigação legal. Comparável à LGPD (PT: RGPD) na proteção de dados - quem não conhece as regras arrisca sanções.
Minha empresa é afetada? Guia por tipo de organização
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.
Tipo de organização
Obrigação?
Explicação
Ltda. / S.A. com loja online
Sim
Comércio online é um serviço ao consumidor. Obrigação plena de acessibilidade.
Empresa com site apenas B2B
Recomendado
A Lei 13.146/2015 tem escopo amplo. Mesmo portais empresariais devem considerar acessibilidade - especialmente se receberem visitantes com deficiência.
Organização sem fins lucrativos
Geralmente sim
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.
Microempresa (MEI / ME)
Recomendado
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.
Associação / ONG com site
Depende
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.
Órgão público
Sim (Lei 13.146 + Decreto 5.296)
Ó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.
O que significa concretamente um "site acessível"?
Acessibilidade soa abstrato, mas é muito prático. Trata-se de que todas as pessoas possam usar seu site. Três exemplos simples:
1.
Uma pessoa cega usa um leitor de tela - 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.
2.
Uma pessoa com baixa visão precisa de bons contrastes. 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.
3.
Uma pessoa com limitação motora não consegue usar o mouse. Se seu site só funciona com cliques do mouse, está bloqueado para essa pessoa. Tudo deve ser acessível também por teclado.
Uma boa acessibilidade melhora ao mesmo tempo a otimização para mecanismos de busca: textos alt, cabeçalhos claros e código limpo ajudam o Google tanto quanto um leitor de tela.
WCAG 2.2 AA: Os quatro princípios explicados
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:
Perceptível
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.
Operável
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.
Compreensível
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).
Robusto
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.
Declaração de acessibilidade: o que deve conter?
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:
Quais partes do site são acessíveis e quais não
Justificativa para limitações ainda existentes
Canal de contato para feedback (e-mail, telefone ou formulário)
Data da última verificação
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.
Por que a acessibilidade vale a pena mesmo sem obrigação
Mesmo que sua empresa não esteja formalmente sujeita a todas as exigências, há boas razões para sites acessíveis:
Maior alcance
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.
Melhor SEO
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.
Requisitos de financiadores
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.
Imagem e confiança
Acessibilidade demonstra responsabilidade social. Para fundações, ONGs e empresas com metas ESG, é um argumento real perante stakeholders e o público.
Consequências do descumprimento
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:
Falta de acessibilidade ou acessibilidade insuficiente em serviços obrigatórios
Ausência de declaração de acessibilidade no site
Descumprimento de determinações da autoridade de fiscalização
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.
Verificação de acessibilidade: 30 minutos, gratuita.
Verificamos seu site nos critérios WCAG mais importantes - sem compromisso e com explicações claras.
25 anos de experiência · Lighthouse 100/100 · WCAG 2.2 AA
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.
--- 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 e por que todo site precisa de uma?
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.
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).
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.
Os erros mais frequentes nas políticas de privacidade
Na nossa prática, vemos sempre os mesmos problemas. Muitos deles são facilmente evitáveis - quando se sabe no que prestar atenção.
Modelos desatualizados
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.
Informações que faltam
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.
Copiar e colar sem adaptar
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áginas vazias ou escondidas
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.
Consentimento de cookies: por que um simples aviso não basta
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.
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.
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.
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.
A melhor solução: não precisar de um banner de cookies
Existe uma alternativa ao dilema do banner de cookies: construa seu site de forma que não instale cookies não essenciais. 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.
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:
LGPD, Marco Civil, CDC - qual lei se aplica a quê?
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.
Legislação
Regula
Obrigação para sites
LGPD
Tratamento de dados pessoais
Política de privacidade, registro de atividades de tratamento, direitos dos titulares
Marco Civil da Internet
Princípios, garantias e deveres para o uso da internet
Proteção de dados, privacidade, guarda de registros de acesso
CDC
Proteção do consumidor
Informação clara e adequada sobre produtos e serviços, incluindo em meios digitais
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.
Caso especial: fundações e organizações sem fins lucrativos
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.
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.
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 Schema.org e fundamentos de SEO ajudam a posicionar o site de forma profissional.
Lista de verificação: 8 pontos que todo site deve cumprir
Independentemente do setor, porte ou forma jurídica - estes oito pontos são o mínimo para todo site no Brasil.
1
Política de privacidade existente e atualizada
Política completa com todas as informações obrigatórias da LGPD. Verificar pelo menos anualmente e atualizar após mudanças legislativas.
2
Identificação clara do responsável
Nome, endereço, e-mail, telefone, CNPJ. Em uma página separada, acessível com no máximo dois cliques.
3
Banner de cookies com consentimento real
Sem "Aceitar tudo" pré-selecionado. Opções equivalentes para aceitar e rejeitar. Somente após o consentimento podem ser instalados cookies não essenciais.
4
Criptografia SSL/TLS ativa
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.
5
Formulários de contato com aviso de privacidade
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.
6
Contratos com operadores de dados firmados
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.
7
Sem integrações de terceiros descontroladas
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.
25 anos de experiência · 800+ projetos · Prática de privacidade desde Hamburgo
O que acontece em caso de infração?
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.
Além das multas, existem dois riscos adicionais que na prática se materializam com mais frequência:
Ações judiciais
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.
Procedimentos da ANPD
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.
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.
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.
--- 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"?
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.
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.
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.
Antes e depois: como Schema.org muda seu resultado de busca
A diferença é visível imediatamente. Veja uma comparação de como sua empresa pode aparecer nos resultados de busca do Google:
Sem Schema.org
Empresa Exemplo Ltda - Início
www.empresa-exemplo.com.br
Bem-vindo à Empresa Exemplo. Oferecemos serviços na área de...
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.
Com Schema.org
Empresa Exemplo Ltda - Serviços de TI São Paulo
www.empresa-exemplo.com.br
★★★★★ 4,8 (127 avaliações)
Rua Exemplo 12, 01310-100 São Paulo - Tel. (11) 1234-5678
Prestador de serviços de TI para PMEs. Servidores, cloud, suporte.
Rich Snippet com estrelas de avaliação, endereço e telefone. Ocupa mais espaço, transmite mais confiança - e recebe mais cliques.
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.
Os três tipos de Schema mais importantes para empresas
Organization
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.
LocalBusiness
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.
BreadcrumbList
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.
Meta-Description: 160 caracteres que decidem o clique
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.
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.
Canonical Tags e hreflang: sinais claros para os buscadores
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:
Canonical Tag: 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.
Hreflang: 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 sites multilíngues em conformidade com a LGPD (PT: RGPD).
Open Graph Tags: como seus links ficam bons no WhatsApp e LinkedIn
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.
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:
og:title - O título que aparece na pré-visualização
og:description - A descrição abaixo do título
og:image - A imagem de pré-visualização (ideal: 1200 x 630 pixels)
og:url - A URL canônica da página
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.
Lista de verificação: 6 fundamentos de SEO para todo site empresarial
Estes seis pontos constituem o fundamento técnico para uma boa visibilidade no Google. Verifique se seu site os cumpre:
1
Configurar marcação Schema.org
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).
2
Meta-Descriptions para todas as páginas importantes
Verifique se cada página tem sua própria Meta-Description - não vazia, não duplicada, máximo 155-160 caracteres.
3
Configurar Canonical Tags
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.
4
Configurar Open Graph Tags
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?
5
Otimizar HTTPS e tempo de carregamento
Verifique se seu site é acessível por HTTPS e carrega em menos de 3 segundos. Ambos são fatores diretos de ranking do Google.
6
Garantir a acessibilidade
Verifique se seu site é acessível conforme a Lei 13.146/2015. 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.
Verificação do potencial SEO do seu site: 30 minutos, gratuita.
Analisamos seu site nos fundamentos de SEO mais importantes e mostramos melhorias concretas.
25 anos de experiência · 800+ projetos · Análise acelerada por IA
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.
--- 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: banners de cookies incomodam todo mundo
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.
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 impactar negativamente o posicionamento SEO.
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 LGPD (PT: RGPD) exige que haja base legal antes de instalar cookies não essenciais.
Mas e se um site não instalar nenhum cookie?
A alternativa: não instalar cookies
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.
Tecnicamente é totalmente viável. Requer decisões conscientes na arquitetura do site:
Fontes hospedadas localmente
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.
Análise sem cookies
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.
Sem embeds de terceiros
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.
SSG + CDN Edge Delivery
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.
O que você ganha
Sem cookie banner
Primeira impressão limpa. Sem popup, sem diálogo de "Aceitar". Os visitantes veem diretamente seu conteúdo.
Melhor desempenho
Sem JavaScript de CMP, sem verificação de consentimento antes de cada script. Menos código, tempos de carregamento mais rápidos.
Plena conformidade LGPD
Não "suficientemente conforme", mas: não há nada a regular. Sem cookies, sem necessidade de consentimento.
Sem custos de CMP
Sem Cookiebot, Usercentrics ou OneTrust. Isso economiza de 600 a 6.000 euros por ano.
Melhor SEO
Os Google Core Web Vitals se beneficiam diretamente da ausência de scripts de consentimento. Páginas mais rápidas posicionam melhor.
À prova de futuro
A regulação de cookies está ficando mais rígida. Quem não precisa de cookies simplesmente não é afetado.
"Mas eu preciso de Analytics!"
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.
Cloudflare Web Analytics
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.
Análise do lado do servidor
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.
Rastreamento de conversões sem cookies
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.
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.
Exemplo prático: gosign.de
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 acessibilidade se beneficia diretamente dessa arquitetura: sem overlay de CMP não há barreira entre o usuário e o conteúdo.
Lista de verificação: assim seu site fica livre de cookies
Cinco passos, nesta ordem. Somente quando os primeiros quatro pontos estiverem resolvidos é que o banner pode ser removido.
1
Remover fontes externas ou hospedá-las localmente
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.
2
Substituir Google Analytics por alternativa sem cookies
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.
3
Substituir ou proteger embeds de terceiros
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.
4
Remover pixels de marketing ou migrar para o lado do servidor
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.
5
Remover o banner de cookies
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.
Solicitar site sem cookies: 30 minutos, gratuito.
Verificamos seu site e mostramos quais cookies você pode eliminar - e quais nem precisa.
25 anos de experiência · 800+ projetos · Prática de privacidade desde Hamburgo
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.
--- 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" e por que isso é importante para você?
LTS significa Long Term Support. 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.
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.
Quais versões do TYPO3 ainda têm suporte?
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:
Versão
Suporte até
Status
TYPO3 v13 LTS
Dezembro 2027
Atual - recomendada
TYPO3 v12 LTS
Outubro 2025 (Extended até março 2028)
Suporte terminando
TYPO3 v11 e anteriores
Já expirado
Sem suporte - risco de segurança
Conclusão: se o seu site roda em TYPO3 v11 ou anterior, ele não recebe mais patches de segurança. Vulnerabilidades conhecidas não são mais corrigidas. Uma atualização é urgentemente recomendada.
O que acontece se você usa uma versão desatualizada?
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.
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 obrigações da LGPD (PT: RGPD) para sites.
O que o TYPO3 v13.4 traz de concreto?
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:
Tempos de carregamento mais rápidos
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.
Backend mais moderno
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.
Segurança atualizada
Suporte para PHP 8.2+ e atualizações de segurança regulares. Seu site permanece protegido contra as ameaças atuais.
Content Blocks
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.
Verificar versão do TYPO3: 30 minutos, gratuito.
Verificamos sua versão do TYPO3, as extensões instaladas e as vulnerabilidades abertas - sem compromisso.
25 anos de experiência · 800+ extensões · Desenvolvimento acelerado por IA
O processo de atualização: o que esperar?
Uma atualização do TYPO3 não precisa ser um grande projeto. O processo típico:
1
Análise
Qual versão está rodando atualmente? Quais extensões estão instaladas? Há personalizações individuais? A Gosign elabora um inventário.
2
Atualização em staging
A atualização é realizada em um ambiente de testes. Seu site em produção continua funcionando normalmente durante todo o processo.
3
Teste e aprovação
Você verifica a versão de staging. Tudo funciona como esperado? Somente após sua aprovação o processo continua.
4
Entrada em produção
A versão atualizada entra em produção. O tempo de inatividade geralmente é inferior a 30 minutos.
Tempo estimado: 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.
Por que hospedagem e manutenção do CMS caminham juntas
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.
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.
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.
--- 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 em RH falham
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?
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.
A IA pode ajudar - mas apenas quando está claro quais regras se aplicam. E quem é o responsável final.
O que é o 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, 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.
Cada decisão é documentada - quem decidiu o quê, quando, com base em quê, com qual resultado. Essa documentação é o ato de decisão: 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.
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.
Como o Decision Layer resolve a Shadow AI e aplica tecnicamente acordos coletivos e regulamentos internos descreve o
Artigo 6 do Blueprint 2026.
Sem Decision Layer
Com Decision Layer
Quem decide?
Não está claro - o agente entrega um resultado
Definido por passo: humano, conjunto de regras ou IA
Regulamentos internos
Seguidos manualmente - ou esquecidos
Armazenados como regras fixas, tecnicamente aplicados
Rastreabilidade
Resultado visível, caminho de decisão não
Documentação completa por decisão
Auditor
Deve revisar manualmente cada caso
Acesso direto à documentação de decisões
Representação de trabalhadores
Bloqueia - sem transparência
Apoia - cada decisão rastreável
Como funciona o Decision Layer na prática?
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.
Por que projetos de IA falham na representação de trabalhadores?
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:
Cada regulamento interno e acordo coletivo é armazenado como uma regra fixa. O agente não pode contorná-lo.
Para decisões que afetam colaboradores, sempre decide um humano. Tecnicamente forçado, não apenas acordado.
Cada decisão de IA está documentada: o que foi verificado, qual regra aplicou, qual foi o resultado.
A representação de trabalhadores pode rastrear como qualquer decisão foi tomada, a qualquer momento.
A diferença: Outros prometem transparência. O Decision Layer a impõe tecnicamente.
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.
Para quem é o Decision Layer?
Head of HR / CHRO
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.
CFO / Head of Finance
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.
Representação de Trabalhadores
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.
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.
O Decision Layer é desenvolvido e implementado pela Gosign GmbH. 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.
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.
--- 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.
O que você encontrará neste assessment
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.
15 perguntas em 5 dimensões
1. Prontidão para auditoria - Quão preparados para auditoria estão seus processos?
2. Sigilo profissional - Status de conformidade regulatória e separação de dados
3. Paisagem ERP - Quão integrados são seus sistemas financeiros?
4. Velocidade de fechamento - Quão rápido é seu fechamento mensal?
5. Maturidade de processos - Quão formalizadas são suas regras contábeis?
Como o eBook se diferencia da ferramenta online
Característica
Online (3 min.)
eBook (PDF)
Perguntas
7
15
Verificação de conformidade
Básica
Aprofundada (6 perguntas)
Avaliação de equipe
Não
Sim (CFO + auditor + TI)
Análise de gaps
Não
Sim
Imprimível
Não
Sim (otimizado A4)
PDF gratuito
Baixar assessment
14 páginas, verificação de conformidade, avaliação de prontidão para auditoria, avaliação de equipe com análise de gaps.
--- 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.
O que você encontrará neste assessment
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.
15 perguntas em 5 dimensões
1. Maturidade de processos - Quão documentados e consistentes são seus processos de RH?
2. Governance - Quem é responsável pela IA em RH?
3. Paisagem de dados - Qual a qualidade dos seus dados de RH?
4. Representação dos trabalhadores - Como o Sindicato ou CRE participa das decisões sobre IA? (PT: Comissão de Trabalhadores)
5. Infraestrutura de TI - Quão integrado é seu ambiente de sistemas de RH?
Como o eBook se diferencia da ferramenta online
Característica
Online (3 min.)
eBook (PDF)
Perguntas
7
15
Gráfico radar
Automático
Modelo para desenhar
Avaliação de equipe
Não
Sim (4-5 participantes)
Análise de gaps
Não
Sim
Imprimível
Não
Sim (otimizado A4)
PDF gratuito
Baixar assessment
14 páginas, planilhas para preenchimento, avaliação de equipe com análise de gaps.
--- 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.
O que você encontrará neste manual
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.
1
Por que o CFO deve liderar a governança de IA em Finanças - não TI
Propriedade da governança, conceito de papéis e checklist do CFO.
2
Três tipos de decisões financeiras: Humano, Regramento, IA
O framework H/R/A com Agent Readiness Score para cada processo financeiro.
3
Regulamentação de IA: Requisitos para o setor financeiro
PL 2338/2023 (PT: equivalente do EU AI Act) e padrões internacionais com checklist de conformidade.
4
Auditores externos como parceiros de governança
NBC TA 315, Auditor Portal, obrigação de AI Literacy.
5
4 processos financeiros no Decision Layer
Contas a pagar, despesas de viagem, fechamento financeiro, detecção de fraude - com taxas Zero-Touch.
6
Avaliação de Prontidão Financeira (10 perguntas)
Onde sua organização se encontra? Autoavaliação com pontuação e recomendações.
7
Plano de 90 dias para começar
Inventário, design, piloto - caminho estruturado ao Decision Layer em três meses.
Baixar gratuitamente
PDF, 28 páginas. Entrega imediata por e-mail.
Checklist de conformidade (Finanças)
Framework de decisões H/R/A
Avaliação de Prontidão Financeira prática
Plano de implementação de 90 dias
Checklist de auditor externo (NBC TA 315)
5 números-chave do manual
5%
do faturamento anual é perdido por fraude no mundo
ACFE 2024
42%
das faturas em contas a pagar ainda são processadas manualmente
Institute of Finance & Management 2024
88-95%
taxa Zero-Touch com Decision Layer em processos financeiros
Projetos de clientes Gosign
1:4-5
proporção de investimento: 1 EUR tecnologia = 4-5 EUR governança
McKinsey 2024
R$ 50M
multa máxima por infração conforme PL 2338/2023
PL 2338/2023
Para quem é este manual?
CFO / VP Finanças
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.
Diretor Financeiro / Gestor de Contabilidade
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?
Auditor externo / Auditoria interna
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?
Finance Compliance / Jurídico
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.
--- 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.
O que você encontrará neste manual
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).
1
Por que o CTO deve liderar o AI Infrastructure Governance
Shadow AI, a lacuna de governança e a lista de verificação do CTO para começar.
2
Build, Buy, Hybrid: o framework B/B/H
Matriz de decisão por tipo de carga de trabalho com custos ocultos e riscos ocultos.
3
EU AI Act: 6 requisitos técnicos (art. 9-15)
Obrigações de conformidade como decisões de infraestrutura com lista de verificação técnica.
4
Security & Data Sovereignty
Data Residency, criptografia, arquitetura Zero Trust e conformidade com LGPD/RGPD no uso de LLM.
5
4 padrões de infraestrutura em produção
Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.
Onde está a sua infraestrutura? Autoavaliação com pontuação e plano de 90 dias.
Baixar gratuitamente
PDF, 28 páginas. Envio imediato por e-mail.
Matriz de decisão Build/Buy/Hybrid
Lista de verificação de conformidade com o EU AI Act (técnica)
4 padrões de infraestrutura prontos para produção
Infrastructure Readiness Assessment + plano de 90 dias
5 números-chave do manual
644 bi
USD em gastos globais com infraestrutura de IA até 2027
Gartner 2024
28%
dos gastos com nuvem desperdiçados por falta de governança
Flexera 2024
82%
operam multi-cloud sem governança centralizada de IA
HashiCorp 2024
40%
dos incidentes de segurança causados por serviços em nuvem mal configurados
ENISA 2024
15 M
EUR multa máxima por violação das obrigações de alto risco
EU AI Act, art. 99
Para quem é este manual?
CTO / VP Engineering
Você é responsável pela estratégia de infraestrutura de IA e precisa de um framework que combine escalabilidade, conformidade e governança de custos.
Responsável de infraestrutura / plataforma
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.
Cloud Architect / DevOps Lead
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?
CISO / Responsável de segurança
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.
--- 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).
O que você encontrará neste manual
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.
1
Por que o CHRO deve liderar a governança de IA em RH - não TI
Propriedade da governança, conceito de papéis e checklist do CHRO.
2
Três tipos de decisões: Humano, Regramento, IA
O framework de decisões com Agent Readiness Score para cada processo de RH.
3
EU AI Act: 6 requisitos obrigatórios em detalhe
Art. 9-15 com checklist de compliance para verificação.
4
Representação dos trabalhadores como parceiro de design
sindicato e CIPA, acordo coletivo como restrição técnica, AI Literacy.
5
4 processos de RH no Decision Layer
Folha de pagamento, despesas de viagem, recrutamento, férias e ausências - com taxas Zero-Touch.
6
Avaliação de prontidão (10 perguntas)
Onde sua organização se encontra? Autoavaliação com pontuação e recomendações.
Baixar gratuitamente
PDF, 25 páginas. Entrega imediata por e-mail.
Checklist de compliance EU AI Act
Framework de decisões (H/R/A)
Avaliação de prontidão prática
Plano de implementação de 90 dias
5 números-chave do manual
73%
das organizações sem framework formal de governança de IA
ISACA 2024
6
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)
EU AI Act, Art. 9-15
85-92%
taxa Zero-Touch com Decision Layer em processos de RH
Projetos de clientes Gosign
1:4-5
proporção de investimento: 1 EUR tecnologia = 4-5 EUR governança
McKinsey 2024
60-80%
menos correções contábeis com regras explícitas
Hackett Group 2024
15M
EUR multa máxima por violação de requisitos de alto risco
EU AI Act, Art. 99
Para quem é este manual?
CHRO / VP RH
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.
Diretor de People Operations
Você implementa processos impulsionados por IA e precisa de regras claras de decisão: o que automatizar e o que não.
Sindicato / CIPA
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?
RH Compliance / Jurídico
Você precisa implementar os requisitos do EU AI Act e precisa de uma checklist de compliance com medidas concretas.
--- 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.
IA em RH
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.
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.
Quão preparada está sua organização para AI Agents? 15 perguntas, planilhas para preencher, avaliação de equipe com análise de lacunas.
HR Agent Readiness
15 perguntas para sua equipe de liderança. Maturidade de processos, governança, paisagem de dados, representação dos trabalhadores, infraestrutura de TI.
Para CHROs e equipe de liderança de RH - 14 páginas
--- 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.
## 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/)
--- 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.
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.
Gratuito, no navegador, sem login
Board Deck Generator
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.
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.
--- 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
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
O problema: lógica contábil na cabeça, não no sistema
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.
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.
Para auditores, revisão interna e centros de serviços compartilhados, isso é um risco sistemático.
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.
O que é um Finance Agent?
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 Decision Layer roteia cada microdecisão: de forma autônoma com alta confiança e regra clara, ao especialista em casos excepcionais.
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.
Cenários de uso concretos
Processamento e classificação de documentos
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.
Lógica de depreciação
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.
Notas de despesas de representação
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.
Correções e garantia de qualidade
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.
Quatro passos: do documento ao lançamento pronto para auditoria
1. Ler e compreender - 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.
2. Avaliar - 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.
3. Decidir - 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.
4. Documentar - 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.
Fluxo de decisão
Documento → Agent extrai → Decision Layer decompõe em etapas
Proposta de conta com score. Autônomo acima do limite.
Humano
Exceção
Especialista revisa e decide com contexto.
Audit Trail por etapa: Regra · Versão · Decisor
Decision Layer: como decisões financeiras se tornam auditáveis
O Decision Layer 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?
O agent lê, compreende e avalia documentos com compreensão real da linguagem. O Decision Layer roteia cada avaliação:
Documento → Extração → Classificação → Avaliação de domínio → Confidence Score → Proposta de lançamento ou escalação humana
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.
Como são os modelos de custos para Enterprise AI e quanto realmente custa self-hosting vs. nuvem está detalhado na comparação TCO no Blueprint 2026.
Cert-Ready by Design
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.
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.
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.
Control Object Structure
Elemento
Função
Control_ID
Identificação única do controle
Technical_Implementation
Implementação técnica concreta (p. ex. política RLS, check API)
Rule_Version
Versão da lógica de decisão subjacente
Evidence_Generator
Mecanismo de verificação automático
Evidence_History
Histórico de resultados de verificação com timestamp
Auditor_View
Visão com drill-down até o nível de implementação
Controles são objetos de dados de primeira classe. Evidências são geradas automaticamente. O auditor vê status ao vivo, não snapshots.
Integração com seu ambiente de sistemas existente
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.
SAP FI/COTOTVSSAP S/4HANASharePointMicrosoft TeamsREST/SOAP
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úblicos-alvo
Firmas de auditoria e consultorias tributárias
Centenas de clientes, milhares de documentos por mês. O Finance Agent traz consistência ao processamento em todos os mandatos.
Centros de serviços compartilhados
Múltiplas entidades, diferentes países, diferentes conjuntos de regras. O Finance Agent aplica regras específicas por mandato de forma consistente.
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.
Build - 3-4 semanas
PoC em produção. Um agent, um processo financeiro, ao vivo na sua infraestrutura. Decision Layer, governance, trilha de auditoria - desde o primeiro dia.
Scale - Contínuo
Mais agents para mais processos financeiros. Correções, notas de despesas, avaliações fiscais, intercompany.
Após 12-18 meses, você opera seus Finance Agents de forma independente.
Business Impact
Resultados mensuráveis em processos financeiros.
Correções contábeis preventivamente eliminadas
Lógica de decisão auditável para auditoria externa e revisão interna
Lógica contábil consistente em todas as localidades e entidades
Risco tributário e de compliance reduzido
Escalabilidade sem perda de conhecimento por rotação
Cert-Ready by Design - estruturalmente pronto para auditoria
Redução do esforço de auditoria mediante atas de decisão completas por documento
Menos ciclos de conciliação interna mediante aplicação consistente de regras
Fechamentos mensais mais rápidos mediante processamento autônomo de rotina
Finance Agent Readiness Assessment
7 perguntas, 3 minutos: Quão preparada está sua organização financeira para AI Agents?
Finance Agent Assessment: 49 agentes avaliados e priorizados
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.
--- Glossário - Termos Enterprise AI ---
> Termos técnicos do mundo Enterprise AI. De Agent a Zero-Trust - claramente definidos, consistentemente utilizados.
## 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.
--- 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.
O Princípio
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.
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.
Três Diferenciadores
Os Controles Vivem no Sistema
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.
As Evidências São Geradas Automaticamente
Nenhuma pessoa coleta evidências. Se um controle não pode gerar sua evidência, isso é um achado.
Drill-Down Completo
Do semáforo no dashboard até a política RLS concreta com o SQL de teste que verifica sua efetividade.
Controles como Objetos de Dados de Primeira Classe
Cada controle na arquitetura da Gosign é um objeto de dados com quatro propriedades:
1. Implementação Técnica
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.
2. Gerador Automático de Evidências
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.
A menor unidade de evidência é o ato de decisão 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).
3. Histórico de Evidências
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.
4. Visão de Auditor com Drill-Down
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.
Cert-Ready Control Object - Estrutura
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.
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.
Dashboard
Visão geral de todos os controles com status semáforo.
Detalhe do Controle
Descrição, implementação técnica, histórico de evidências.
Drill-Down
Da visão geral até o resultado concreto do teste.
Exportação
Pacotes de evidência em JSON ou PDF.
Histórico de Alterações
Quando, por quem, por quê.
Histórico de Overrides
Quando um override humano anulou uma decisão do agente.
Mapeamento de Frameworks
Estruturalmente preparado para qualquer framework.
ISO 27001: Controles mapeados para medidas do Anexo A. Evidências geradas automaticamente.
SOC2: Trust Service Criteria (CC6, CC7, CC8) como categorias de controle.
PS 951: Padrão de auditoria para provedores de TI. Controles e evidências preparados para auditores.
EU AI Act: Artigos 9, 12, 13, 14, 15 e 51 implementados como controles no sistema.
O mapeamento muda. A estrutura permanece idêntica.
O Que Cert-Ready by Design Não É
Não é uma promessa de certificação. Significa que a arquitetura está estruturalmente preparada para ser auditada e certificada a qualquer momento.
Não é uma ferramenta GRC. Complementa plataformas GRC existentes.
Não é uma auditoria única. É contínuo. O sistema está sempre em modo de auditoria.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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.
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, 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. Este checklist traduz as dez lacunas em 25 perguntas concretas de verificação.
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)?
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.
--- 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.
Por Que Participação dos Trabalhadores É um Tema de Arquitetura
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.
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.
Marco Legal
CLT (PT: Código do Trabalho) - Direitos de informação e participação
Brasil: 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.
Portugal: 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.
Planejamento de mudanças tecnológicas
Brasil: 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.
Portugal: 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.
Implementação Arquitetônica
Acordos Coletivos como Restrições do Sistema
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.
Human-in-the-Loop Arquitetônico
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.
RBAC Baseado em Funções
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.
Audit Trail para a Representação dos Trabalhadores
Cada decisão do agente é documentada em um Audit Trail imutável. A representação dos trabalhadores pode verificar cada decisão.
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.
O Que Não Fazemos
Participação dos trabalhadores para AI Agents é um tema de arquitetura.
Não substituímos acordos coletivos. Mapeamos tecnicamente.
Não fornecemos assessoria jurídica. Entregamos a infraestrutura técnica.
Não automatizamos decisões sujeitas à participação dos trabalhadores sem Human-in-the-Loop.
A arquitetura da Gosign assegura tecnicamente que acordos coletivos sejam respeitados e que Human-in-the-Loop seja imposto onde necessário.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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
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 Decision Layer 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.
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 arquitetura de governança completa garante que todo processamento de dados seja documentado e rastreável.
Opções de Implantação
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.
Azure
Regiões Azure 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.
GCP
Regiões GCP 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.
AWS
Regiões AWS 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.
Vercel + Supabase
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.
Self-Hosted
Datacenter próprio ou servidores próprios. Modelos open-source: Llama, Mistral, DeepSeek - operados localmente. Nenhum dado sai da rede corporativa. Controle total sobre hardware, software e rede.
Híbrido
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.
Medidas Técnicas de Proteção de Dados
Row-Level Security (RLS)
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.
Criptografia
Em repouso: Todos os dados são armazenados criptografados (AES-256)
Em trânsito: Todas as transferências de dados via TLS 1.3
Gestão de chaves: Chaves próprias do cliente (Bring Your Own Key) ou gerenciadas pela plataforma
Controle de Acesso
RBAC (Role-Based Access Control) em todos os níveis
Sem credenciais compartilhadas, sem conta de serviço com acesso total
Acessos são registrados e rastreáveis no Audit Trail
Gosign sem acesso permanente a dados de produção
Exclusão de Dados
Conceito de exclusão segundo LGPD (PT: RGPD) Art. 16 / RGPD Art. 17
Períodos de retenção configuráveis por tipo de dado
Exclusão abrange todas as cópias - banco de dados, Audit Trail, backups (após expiração da retenção de backup)
Protocolos de exclusão documentados no Audit Trail
Proteção de Dados Específica para LLM
LLMs na Nuvem (Azure OpenAI, Vertex AI, Amazon Bedrock)
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 anonimização de PII garante que dados pessoais sejam removidos antes do processamento pelo LLM.
Modelos Self-Hosted (Llama, Mistral, DeepSeek)
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 Hosting de IA: EU SaaS, data center europeu ou Self-Hosted?
Sem Treinamento com Dados do Cliente
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.
Mapeamento LGPD (PT: RGPD) e RGPD
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 EU AI Act.
Área
LGPD (Brasil)
RGPD (Portugal/UE)
Solução Gosign
Minimização de dados
Art. 6, III LGPD
Art. 5 RGPD
Somente dados necessários são processados
Base legal
Art. 7 LGPD
Art. 6 RGPD
Processamento por contrato (Art. 7, V) ou interesse legítimo
Exclusão de dados
Art. 16 LGPD
Art. 17 RGPD
Conceito de exclusão com períodos configuráveis
Privacy by Design
Art. 46 LGPD
Art. 25 RGPD
RLS, criptografia, RBAC como componentes arquitetônicos
Processamento por terceiros
Art. 39 LGPD
Art. 28 RGPD
DPA entre cliente e Gosign, DPA com provedor cloud
Registro de operações
Art. 37 LGPD
Art. 30 RGPD
Audit Trail documenta todas as operações
Segurança
Art. 46 LGPD
Art. 32 RGPD
Criptografia, controle de acesso, revisão regular
Notificação de incidentes
Art. 48 LGPD
Art. 33/34 RGPD
Processo de resposta a incidentes, Audit Trail para análise forense
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.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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.
EU AI Act - Relevância para AI Agents Empresariais
O EU AI Act (Regulamento (UE) 2024/1689) 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.
Mapeamento Arquitetônico do EU AI Act
Requisito
Artigo
Implementação Gosign
Transparência
Art. 13
Decision Layer documenta cada rota de decisão completamente: entrada, modelo e versão, avaliação, confiança, regra aplicada, decisão resultante.
Supervisão Humana
Art. 14
Human-in-the-Loop é roteamento imposto arquitetonicamente. Este roteamento não pode ser contornado. Cada override é documentado.
Obrigações de Registro
Art. 12
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.
Gestão de Riscos
Art. 9
Monitoramento de viés, rastreamento de confiança, detecção de anomalias e controles Cert-Ready com geração automática de evidências.
Explicação da decisão individual
Art. 86 (e LGPD art. 20)
O ato de decisão é 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.
Cinco Respostas Arquitetônicas
Compliance não é uma verificação posterior, mas resultado da arquitetura.
1
Decision Layer: Transparência e Explicabilidade
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.
2
Human-in-the-Loop: Supervisão Humana
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.
3
Governance Layer: Gestão de Riscos e Monitoramento
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.
4
Audit Trail: Obrigações de Registro
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.
5
Ato de Decisão: Explicação e Contestabilidade do Caso Individual
O artigo 86 dá ao afetado o direito a uma explicação da decisão individual - e a LGPD art. 20 já garante esse direito de revisão hoje no Brasil. O ato de decisão é 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.
Classificação de Risco
Potencialmente Alto Risco: AI Agents que preparam ou influenciam decisões de pessoal, avaliação de crédito, acesso a serviços essenciais.
Não Alto Risco (tipicamente): Document Agents que classificam documentos sem decisões de pessoal, Knowledge Agents que fornecem informação sem tomar decisões.
A arquitetura está preparada para os requisitos mais rigorosos.
Posição de Compliance
EU AI Act compliant by design.
Nossa arquitetura aborda os requisitos do EU AI Act como princípios de design.
Transparência, explicabilidade e supervisão humana são estruturalmente inevitáveis, não opcionalmente configuráveis.
Cada decisão é documentada automaticamente, não reconstruída posteriormente.
Cada microdecisão gera um ato de decisão 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.
O sistema está preparado para requisitos de alto risco, independentemente da classificação concreta do caso de uso.
Controles Cert-Ready garantem que evidências estejam sempre disponíveis e exportáveis.
Distinção
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.
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.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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.
Por que sete camadas
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.
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.
1. Presentation Layer
A interface entre sistema e usuário. Sem lógica de negócio, sem decisões - apenas apresentação e entrada de dados.
Chat UI: Interface web para usuários finais (analistas de RH, contadores). PWA-ready, responsiva.
Dashboard: 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.
Portal de Auditor: Acesso de auditores ao Audit Trail, controles e evidências. Somente leitura. Para auditores independentes (PT: revisores oficiais de contas), sindicatos e auditoria interna.
REST API: Interface legível por máquina para integração com sistemas existentes. Versionada, documentada, autenticada.
2. Orchestration Layer
Coordena o fluxo de dados entre agentes, sistemas e usuários. Gerencia workflows, filas e roteamento de APIs.
Motor de Workflow: Engines open-source (Trigger.dev, Camunda) para processos complexos e multietapa. Workflows visuais, integração via API, webhooks.
API Gateway: Ponto de entrada unificado com rate limiting, autenticação, logging, monitoramento.
Sistema de Filas: Processamento assíncrono para processos em lote (fechamento mensal, importação em massa).
Sistema de Eventos: Reação em tempo real a documentos recebidos, mudanças de status, escalações.
3. Agent Layer
AI Agents especializados que executam tarefas de domínio. Cada agente tem um escopo definido e opera dentro dos limites estabelecidos pelo Decision Layer.
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.
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.
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.
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.
Rules Engine: 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.
Confidence Routing: 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.
Human-in-the-Loop: 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.
Audit Trail - o ato de decisão: 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).
A camada LLM. Intercambiável, agnóstica de modelo, desacoplada da lógica de negócio.
Cloud-LLMs
Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - via regiões Brasil ou UE dos respectivos provedores de nuvem.
LLMs Open-Source / Open-Weight
Llama (Meta), Mistral, DeepSeek, gpt-oss (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.
Híbrido
Cloud-LLMs para casos padrão, Self-Hosted-LLMs para dados sensíveis. Roteamento automático conforme classificação de dados.
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.
Entre a lógica de negócio e o Model Layer, a arquitetura prevê um gateway de redação (PII Gateway): cada chamada ao modelo - cloud ou self-hosted - passa por ele. Seu objetivo de design: dados pessoais não saem do perímetro de confiança do operador em texto em claro. Para cargas de trabalho sujeitas a sigilo profissional (advocacia, contabilidade, saúde), o gateway é um dos pilares da minimização de dados prevista na LGPD - complementa salvaguardas organizacionais e contratuais, não as substitui.
Redação e reinserção: Antes de cada chamada ao modelo, o gateway substitui nomes, identificadores e outros atributos pessoais por marcadores (pseudonimização). O modelo trabalha exclusivamente sobre o texto redigido. Os valores originais são reinseridos após a resposta - dentro do perímetro de confiança, nunca no provedor do modelo.
Audit Trail sem texto em claro: Cada chamada ao modelo é registrada append-only e encadeada por hashes: valores de hash do prompt e da resposta bruta em vez de texto em claro, além do ID do modelo, da versão da API e da versão do conjunto de regras de redação. A evidência do que passou pelo gateway, e quando, permanece completa - sem que o próprio registro se torne um acervo de dados sensíveis.
Regras de break-glass: Acessos excepcionais para incidentes e auditorias estão previstos no design - nunca em silêncio: princípio dos quatro olhos, justificativa documentada, limite de tempo, e cada uso de break-glass fica registrado integralmente no Audit Trail.
Aprovação pelo usuário em baixa confiança: Se a confiança da redação em um trecho é baixa, a decisão vai para o usuário na interface - nunca para a equipe da Gosign. A escalação permanece na esfera em que os dados já são conhecidos.
Modos de API que não podem ser redigidos - por exemplo, chamadas externas de embeddings cujos vetores não admitem pseudonimização - são bloqueados para conteúdos sujeitos a redação, em vez de repassados em silêncio. As tabelas de mapeamento entre marcadores e valores originais são efêmeras ou criptografadas por inquilino com tempo de vida definido (TTL); as chaves de provedor ficam exclusivamente no sistema de gerenciamento de chaves (KMS).
A conexão com sistemas empresariais existentes. O agente não substitui sistemas - ele os complementa.
Categoria de sistema
Integração
ERP / Finanças
SAP FI/CO, SAP S/4HANA, TOTVS, Oracle Financials
RH / Folha
SAP SuccessFactors, Workday, TOTVS RM
Colaboração
SharePoint, Microsoft Teams (via Microsoft Graph)
DMS / ECM
SharePoint, d.velop, ELO, nscale
Outros
Qualquer sistema com interface REST ou SOAP
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.
7. Infrastructure Layer
O fundamento de deployment. Toda a arquitetura roda na infraestrutura do cliente - não na Gosign, não em terceiros.
Cloud (Brasil e UE): Azure, AWS ou GCP - regiões no Brasil (São Paulo) e na UE. Managed Kubernetes, Managed Databases, LLM Hosting.
Managed (Brasil ou UE): Vercel EU + Supabase (região sa-east-1 São Paulo ou UE). Opção leve sem infraestrutura Kubernetes própria.
Self-Hosted: Servidores próprios, datacenter próprio. Docker/Kubernetes, LLMs open-source em GPUs próprias. Total independência do Cloud Act.
Híbrido: Combinação conforme classificação de dados. Cargas sensíveis self-hosted, cargas padrão na nuvem.
Todas as camadas acima da infraestrutura permanecem idênticas - independentemente do modelo de deployment.
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.
Presentation: Acesso baseado em funções, Portal de Auditor
Orchestration: Logging de workflows, documentação de escalações
Agent: Decisões de agentes geram entradas no Audit Trail
Operação em produção não é retrabalho, é componente da arquitetura. A arquitetura de 7 camadas foi projetada para operação sob carga.
Orquestração de Containers: Deployment baseado em Kubernetes. Cada camada roda em seus próprios containers, escalável independentemente.
Escalabilidade Horizontal: Agent Layer e Model Layer escalam horizontalmente conforme a utilização. Um novo agente significa mais pods, não mais arquitetura.
Health Checks e Self-Healing: Liveness e Readiness Probes em todos os containers. Reinício automático em caso de falha, redirecionamento automático em caso de sobrecarga.
Monitoramento e Alertas: Métricas Prometheus em todas as camadas. Dashboards Grafana para latência, throughput, taxas de erro, profundidade de fila. Alertas ao ultrapassar limiares.
CI/CD: Deployments baseados em GitOps. Infrastructure as Code (Terraform/Pulumi). Testes automatizados, deployments Blue-Green ou Canary.
Arquitetura de Dados
Dados fluem por todas as sete camadas. A arquitetura define onde os dados são criados, como são armazenados e quem tem acesso.
Fluxo de dados: Input (documento, consulta) - Agent (análise) - Decision Layer (decisão) - Integration (exportação para sistema destino). Cada etapa gera uma entrada no Audit Trail.
Vector Store: PostgreSQL com pgvector para busca semântica (RAG). Conhecimento empresarial é armazenado como embeddings, não transmitido a serviços externos.
Isolamento de inquilinos: 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.
Criptografia: 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).
Retenção de dados: 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.
Backup e Recovery: Backups automatizados, Point-in-Time Recovery. Recovery Point Objective (RPO) e Recovery Time Objective (RTO) configurados por inquilino.
Arquitetura de Interfaces
A arquitetura se comunica por interfaces definidas - internamente entre camadas e externamente com sistemas de origem e destino.
REST API: APIs versionadas (v1, v2) com documentação OpenAPI. Breaking changes apenas em novas versões, versões anteriores operam em paralelo.
Event-Driven: Processamento de eventos baseado em webhooks para reações em tempo real. Documento recebido - evento - agente processa. Sem polling, sem atraso de lote.
MCP (Model Context Protocol): Protocolo padronizado para integração de ferramentas em agentes LLM. Agentes acessam ferramentas externas via MCP - tipado, documentado, auditável.
Processamento em lote: 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.
API Gateway: Ponto de entrada central. Autenticação (SSO/OIDC), rate limiting, logging de requisições, monitoramento. Desacopla a arquitetura interna dos consumidores externos.
Princípios de Design
Agnóstico de modelos: 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.
Agnóstico de infraestrutura: Mesma arquitetura em Azure, AWS, GCP, Self-Hosted ou Híbrido. A escolha da infraestrutura é uma decisão do cliente, não da arquitetura.
Agnóstico de sistemas: 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.
Governance by Design: Audit Trail, RBAC, Decision Layer e Human-in-the-Loop são componentes arquitetônicos - não funcionalidades opcionais adicionadas depois.
Cert-Ready by Design: 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.
Acesso ao código: 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.
--- 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 by Design
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.
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.
Cinco Dimensões de Governança
1. Audit Trail e Rastreabilidade
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 LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).
2. Decision Layer
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.
3. Cert-Ready by Design
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.
4. Representação de Trabalhadores e Sindicatos (PT: Comissão de Trabalhadores)
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.
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.
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.
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.
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.
--- 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
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.
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.
Por que a maioria dos projetos de IA não gera benefícios mensuráveis
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.
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.
O Decision Layer é 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.
AI Agents para o seu departamento
AI Agents para Finance & Auditoria
Decision Automation para processamento de documentos, contabilização e preparação de auditoria. Regras versionadas, trilha de auditoria completa, Cert-Ready by Design. O Decision Layer torna cada decisão contábil rastreável.
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.
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.
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.
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.
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.
Comparação de arquiteturas: Copilot, SaaS Agent, Gosign
Três abordagens para AI empresarial - diferentes arquiteturas, diferentes consequências.
Dimensão
Gosign Agent Architecture
Microsoft Copilot
SaaS AI Agent
Profundidade de decisão
Decisões de domínio com Decision Layer
Assistência e sugestões
Workflows pré-configurados
Auditabilidade
Trilha de auditoria completa até nível SQL
Logging básico
Logging de plataforma
Acesso ao código
Acesso completo ao código-fonte · Configurações com o cliente · Sem vendor lock-in
Microsoft detém o código
Plataforma detém o código
Escolha de modelo
Agnóstico (GPT, Claude, Gemini, Llama, Mistral)
GPT (vinculado à Microsoft)
Vinculado à plataforma
Governance
Governance Layer próprio, Cert-Ready Controls, Portal do Auditor
Azure governance
Governance da plataforma
Human-in-the-Loop
Arquitetonicamente forçado em decisões de risco
Opcional
Configurável
EU AI Act
Compliant by design
Roadmap da Microsoft
Dependente do provedor
Representação dos Trabalhadores
Templates, logging, conceitos de papéis para sindicatos e CRE
Sem suporte específico
Sem suporte específico
Infraestrutura
Infraestrutura do cliente (Azure, GCP, AWS, self-hosted, híbrido)
Microsoft Cloud
Nuvem do provedor
Estratégia de saída
Operação independente após 12-18 meses
Migração de plataforma
Migração de plataforma
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.
Governance by Design
Agents só escalam com infraestrutura. Sem governance, AI permanece um piloto - com infraestrutura, torna-se escalável.
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.
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.
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.
EU AI Act compliant by design: transparência, explicabilidade e supervisão humana são arquitetonicamente integradas - não adicionadas depois.
Definição: Decision Layer
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?
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.
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.
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.
2
Build
3-4 semanas
PoC em produção. Um agente, um processo, ao vivo na sua infraestrutura. Decision Layer, governance, trilha de auditoria - desde o primeiro dia.
3
Scale
Contínuo
Mais agentes, mais departamentos, mais localidades. A arquitetura cresce com seus requisitos. Mesmo governance, mesma infraestrutura.
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.
--- 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.
Um HR Agent não automatiza genericamente, mas decompõe processos em micro-decisões. Para cada decisão, o Decision Layer define: humano, conjunto de regras ou IA. (PT: Em Portugal, as Comissões de Trabalhadores exercem papel similar ao dos sindicatos brasileiros.)
Onboarding, transferências internas, desligamento em um pipeline auditável.
Coming
Candidate Screening Decision Layer
Alto risco conforme EU AI Act (BR: PL 2338/2023). Monitoramento de viés. Participação sindical nas diretrizes de seleção.
Por que você deveria começar com processos entediantes
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.
eBook gratuito: IA em RH
Checklist regulatório, Decision Framework, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para RH.
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.
Atestado médico
Micro-decisão
Quem decide
Por que
Verificar período de remuneração durante afastamento
AI autônomo
Verifica TODOS os critérios da convenção coletiva - mais consistente que qualquer especialista
Avaliar obrigação de reintegração (> 6 sem. em 12 meses)
Humano
Representação dos trabalhadores requer human-in-the-loop, risco de discriminação com dados de saúde
Informar gestor sobre ausência
AI autônomo
Informação consistente - apenas ausência e duração, sem diagnóstico
Onboarding
Micro-decisão
Quem decide
Por que
Enquadramento na convenção coletiva
Humano
Sindicato tem direito de consulta sobre enquadramento (CLT)
Baseado na descrição do cargo, proposta para revisão
Formular avaliação de desempenho
Humano
Avaliação individual, gestor é responsável
Verificar conformidade legal
AI + Humano
AI verifica contra padrões conhecidos e sinaliza riscos, humano decide final
O padrão: Rotina e regras são automatizadas pelo agent. Decisões discricionárias e juridicamente sensíveis permanecem com humanos. Cada passo documentado.
O Decision Layer 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.
Cada decisão gera um registro completo: entrada, regra, versão, confiança, resultado, timestamp. Verificável para sindicatos, auditores e compliance interno.
Governance e representação dos trabalhadores
Human-in-the-Loop como princípio arquitetônico
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.)
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 artigo sobre Sindicatos & AI Literacy.
EU AI Act Readiness
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.
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.
Do PoC à plataforma
Discover - 1 semana
Análise de processos, compreensão de regras, priorização de use cases. Qual processo tem o maior potencial de erro?
Build - 3-4 semanas
PoC produtivo. Um agent, um processo, em produção na sua infraestrutura com Decision Layer e Audit Trail.
Scale - Contínuo
Mais agents, mais processos. Mesmo governance, mesma auditabilidade. Após 12-18 meses você opera seus agents de forma independente.
HR Agent Readiness Assessment
7 perguntas, 3 minutos: Quão preparada está sua organização de RH para AI Agents?
Catálogo de agentes HR: 48 agentes avaliados e priorizados
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.
11 domínios, 3 quadrantes interativos de priorização, tabelas de micro-decisões para cada agente.
--- 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.
Assinatura cancelada
Você foi removido do AI Governance Briefing e não receberá mais e-mails.
Se desejar se inscrever novamente, você pode fazer isso a qualquer momento em nosso site.
--- Link expirado - Gosign GmbH ---
> Seu link de confirmação para o AI Governance Briefing expirou.
Link de confirmação expirado
Seu link de confirmação para o AI Governance Briefing expirou. Por motivos de segurança, os links são válidos por 7 dias.
Sem problema - basta se inscrever novamente abaixo. Você receberá um novo e-mail de confirmação imediatamente.
--- 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.
Compliance-ready
Cada decisão do Agent rastreável. Para o Sindicato. Para o regulador. Para você.
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.
Gosign-Agents tornam cada decisão transparente - arquitetonicamente, não retroativamente:
Art. 9 Gestão de riscos - O Decision Layer define para cada etapa do processo antecipadamente: pessoa, regra ou IA. Avaliação de risco é arquitetura, não projeto de auditoria.
Art. 12 Obrigações de registro - 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.
Art. 13 Transparência - O Sindicato pode acompanhar cada decisão pelo portal de auditoria - sem departamento de TI, sem acesso a banco de dados.
Art. 14 Supervisão humana - 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.
Transparência de decisões não é um projeto de compliance retroativo. Está integrada no Decision Layer - desde o primeiro piloto.
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.
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.
Código-fonte
Acesso completo. Você pode operar o Agent a qualquer momento sem a Gosign. Sem vendor lock-in.
Modelo-agnóstico
Você escolhe o LLM - não nós. OpenAI, Anthropic, modelos locais. Sem lock-in em um fornecedor.
LGPD nativa
Residência de dados como decisão de arquitetura. Não como funcionalidade retroativa. Nenhum dado sai da sua infraestrutura.
EU-first
Nenhum produto americano com patch europeu. A regulação UE é a baseline.
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.
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.
Na prática, isso significa:
Sem dependência de cloud americana. Os dados permanecem na sua infraestrutura - sem exposição ao CLOUD Act, sem risco de transferência transfronteiriça.
LGPD como princípio de arquitetura, não como adaptação retroativa. Residência de dados, conceitos de exclusão e controles de acesso estão ancorados na arquitetura.
Acordos coletivos como regras determinísticas no Decision Layer. CCT, ACT, convenções setoriais - cada acordo coletivo é implementado como motor de regras, não como campo de texto livre.
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.
--- 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.
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 (§ 38, parágrafo 1, BDSG). Para questões relacionadas à proteção de dados, entre em contato pelo endereço indicado acima.
2. Visão geral
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 4).
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 (§ 25 TTDSG).
3. Hospedagem e distribuição de conteúdo
Este site é disponibilizado por meio do Cloudflare Pages. O Cloudflare atua como operador de dados conforme o Art. 28 do RGPD. Um Adendo de Tratamento de Dados (DPA) com Cláusulas Contratuais Padrão (SCCs) está em vigor.
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.
Base legal: Art. 6(1)(f) RGPD (interesse legítimo na disponibilização segura e eficiente do site).
4. Medição de alcance e conversões
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:
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.
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.
Base legal: Art. 6(1)(f) RGPD (interesse legítimo na análise do uso do site e na eficácia da nossa publicidade).
Medição de conversões para campanhas publicitárias (Google Ads)
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. 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).
Base legal: Art. 6(1)(f) RGPD (interesse legítimo na medição e otimização da nossa publicidade).
Você pode se opor a essa medição a qualquer momento, com efeito para o futuro (Art. 21 RGPD). Basta uma mensagem informal para o endereço indicado em "Responsável pelo tratamento"; então cessaremos o tratamento.
5. Formulário de contato e contato por e-mail
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. 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. 6(1)(f) RGPD).
Processamento técnico via Cloudflare (sem armazenamento intermediário)
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.
Hospedagem de e-mail via Google Workspace (hospedagem na UE)
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).
Contratos de tratamento de dados (DPA) e transferência para países terceiros
Celebramos contratos de tratamento de dados (DPA) conforme o Art. 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 % 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.
Período de retenção
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 § 257 HGB e § 147 AO), permanecem inalterados.
6. Newsletter
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.
Procedimento de dupla confirmação (Double Opt-In)
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.
Serviços utilizados
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. 28 do RGPD. O envio de e-mails ocorre via SMTP (atualmente por meio de um servidor de e-mail de terceiros).
Base legal
Art. 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. 13.709/2018) prevê o consentimento como base legal (art. 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.
Período de retenção
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.
7. 203-Readiness-Check
Em nossas páginas em alemão oferecemos o 203-Readiness-Check, uma autoavaliação voluntária sobre o uso de IA destinada a profissionais sujeitos ao sigilo profissional nos termos do § 203 do Código Penal alemão (StGB). Suas respostas na autoavaliação não são armazenadas nem transmitidas - a avaliação ocorre integralmente em seu navegador e o resultado aparece diretamente na página, sem necessidade de informar um e-mail.
Relatório de resultados por e-mail (opcional)
Somente se você solicitar voluntariamente o relatório de resultados detalhado por e-mail, tratamos seu endereço de e-mail, seu grupo profissional e o nível recomendado para você - mas não suas respostas. A solicitação é confirmada por meio do procedimento de dupla confirmação (double opt-in), como no newsletter (seção 6): você recebe um e-mail de confirmação com um link único, e o relatório só é enviado após o clique nesse link. O envio é realizado por meio do nosso provedor de serviços de e-mail Brevo, com o qual celebramos um contrato de tratamento de dados conforme o Art. 28 do RGPD.
Base legal
Art. 6(1)(a) RGPD (consentimento). De forma complementar, a Lei Geral de Proteção de Dados (LGPD, Lei n.º 13.709/2018) prevê o consentimento como base legal (art. 7, I). Você pode revogar seu consentimento a qualquer momento com efeito futuro, por exemplo, por e-mail para datenschutz@gosign.de.
Período de retenção
As solicitações de relatório confirmadas são excluídas após 6 meses. Solicitações não confirmadas no procedimento de dupla confirmação expiram automaticamente após 7 dias.
8. Agendamento de reuniões
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.
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 Política de Privacidade do Google.
Base legal: Art. 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.
9. Fontes tipográficas
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.
10. Mapas e vídeos
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.
11. Nenhum outro terceiro
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:
Google Tag Manager
Facebook Pixel
LinkedIn Insight Tag
HubSpot, Salesforce ou outros rastreadores de CRM
Hotjar, Mouseflow ou outras ferramentas de gravação de sessão
Matomo ou outras ferramentas de análise auto-hospedadas
12. Criptografia SSL/TLS
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.
13. Arquivos de log do servidor
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.
Base legal: Art. 6(1)(f) RGPD (interesse legítimo em garantir o funcionamento técnico e a detecção de ataques).
14. Inteligência artificial e tomada de decisão automatizada
Não ocorre tomada de decisão automatizada, incluindo perfilamento, nos termos do Art. 22 RGPD. Nenhum sistema de IA é utilizado neste site para o tratamento automatizado de dados pessoais dos visitantes.
Criação de conteúdo assistida por IA
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.
IA em projetos de clientes
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. 28 RGPD, e não é objeto desta política de privacidade.
15. Padrões internacionais de proteção de dados
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.
Reino Unido
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.
Estados Unidos
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.
Suíça
Para usuários na Suíça, aplica-se a Lei Federal de Proteção de Dados revisada (revDSG/nDSG), em vigor desde 1.º 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ÖB), Berna.
Canadá
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.
Brasil
Para usuários no Brasil, aplica-se de forma complementar a Lei Geral de Proteção de Dados (LGPD, Lei n.º 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.
Índia
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.
Japão
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.
África do Sul
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.
Todas as demais jurisdições
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.
16. Seus direitos
Você possui os seguintes direitos em relação aos seus dados pessoais:
Acesso (Art. 15 RGPD): Você pode solicitar informações sobre os dados que tratamos.
Retificação (Art. 16 RGPD): Você pode solicitar a correção de dados incorretos.
Exclusão (Art. 17 RGPD): Você pode solicitar a exclusão dos seus dados, desde que não existam obrigações legais de retenção.
Limitação do tratamento (Art. 18 RGPD): Você pode solicitar a limitação do tratamento.
Portabilidade dos dados (Art. 20 RGPD): Você pode solicitar a entrega dos seus dados em formato legível por máquina.
Oposição (Art. 21 RGPD): Você pode se opor ao tratamento com base no Art. 6(1)(f) RGPD a qualquer momento.
Revogação do consentimento (Art. 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.
Para exercer seus direitos, basta uma comunicação informal ao endereço indicado acima.
17. Direito de reclamação
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:
Comissário de Hamburgo para Proteção de Dados e Liberdade de Informação (Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit)
Ludwig-Erhard-Str. 22
20459 Hamburgo, Alemanha
18. Atualidade
Esta política de privacidade está atualmente em vigor. Última atualização: fevereiro de 2026.
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.
--- 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.
O Problema: Screening Inconsistente, Decisões Não Documentadas
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.
Processo de recrutamento com Decision Layer
Como Funciona o Recruiting Agent
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
Quem decide o quê? Micro-Decisions no recruiting
O Decision Layer decompõe o processo de recruiting em passos de decisão individuais. Para cada passo, é definido antecipadamente: pessoa, conjunto de regras ou AI.
Passo de decisão
Quem decide
Por quê
Criar perfil de requisitos
Pessoa revisa
AI gera proposta a partir da descrição da vaga e perfil da equipe. Gestor revisa e ajusta.
Redigir anúncio de vaga
Automático
Agent gera texto a partir dos requisitos. Verificação contra linguagem discriminatória.
Parsing de CV e extração de dados
Automático
Extração de dados estruturados de CVs. Caso padrão, alta confiança.
Matching de requisitos (screening)
Conjunto de regras
Comparação contra critérios obrigatórios definidos. Baseado em regras, não em julgamento de AI.
Avaliação qualitativa (shortlist)
Pessoa revisa
Agent cria shortlist com justificativa. Recrutador revisa e decide sobre convites.
Coordenação de entrevistas
Automático
Sincronização de calendários, convites, lembretes. Processo padrão.
Realizar entrevista
Pessoa decide
Conversa pessoal. Não automatizável.
Decisão de contratação
Pessoa decide
Decisão de pessoal. Sindicatos e CRE possuem direito de participação (CLT). Discricionário.
Criar oferta contratual
Conjunto de regras
Classificação segundo CCT / faixa salarial. Lógica determinística.
Formular rejeição
Automático
Rejeição padrão quando critérios obrigatórios claramente não são atendidos. Casos limítrofes são escalados.
Por que AI no recruiting é alto risco - e o que isso significa
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.
Bias Monitoring é obrigatório
Certos grupos são avaliados sistematicamente de forma diferente? O Decision Layer monitora estatisticamente todas as decisões de screening e sinaliza anomalias.
Supervisão humana forçada arquitetonicamente
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.
Transparência para candidatos
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.
Audit Trail por decisão
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.
Como a representação dos trabalhadores supervisiona AI no recruiting?
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?
O Decision Layer fornece à representação dos trabalhadores exatamente essa transparência:
✓
Critérios são transparentes: As regras de screening são conjuntos de regras versionados e documentados - não uma caixa-preta.
✓
Decisões de contratação ficam com pessoas: O agent sugere, a pessoa decide. Forçado arquitetonicamente, não opcional.
✓
Audit Trail para cada candidatura: Qual critério levou ao convite ou rejeição? Rastreável no portal de auditoria.
✓
Relatório de viés para a representação dos trabalhadores: Análise estatística de todas as decisões de recruiting. Certos grupos são tratados sistematicamente de forma diferente?
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.
Reduzir o tempo de contratação
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.
Avaliação consistente
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.
Mais tempo para candidatos
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.
Casos de Uso
Matching de Requisitos
CV contra perfil de requisitos. Cada critério verificado, cada lacuna documentada. Consistente em todas as posições.
Screening de Volume
Centenas de candidaturas, mesmo padrão de qualidade. Sem viés por fadiga, sem inconsistência entre avaliações matutinas e noturnas.
Documentação de Compliance
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.
Governance e Compliance
Decisão Humana: A decisão de contratação é sempre humana. O agent avalia e documenta.
Prevenção de Viés: Avaliação contra critérios definidos. Dados demográficos excluíveis arquitetonicamente.
EU AI Act + LGPD: Alto risco. Transparência, supervisão humana e registro atendidos by design.
Audit Trail: Cada decisão de screening documentada, versionada, exportável.
Quando começar? Priorização e prontidão de governança
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.
--- 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 e engenharia
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.
O que a Gosign constrói para clientes da indústria
Sites B2B: responsivos, performáticos, com buscador de produtos e roteamento de contato para o distribuidor correto
Configuradores de produto: configuradores interativos que consultam parâmetros técnicos e recomendam produtos adequados
Portais de distribuidores: áreas protegidas por login para parceiros de vendas: listas de preços, documentação técnica, ferramentas de pedidos
Catálogos multilinguais: catálogos de produtos baseados em TYPO3 com integração PIM, tradução automática e variantes regionais
Ferramentas digitais de vendas: apresentações de produto para tablet, catálogos offline, geradores de propostas comerciais
Tecnologias no ambiente industrial
Requisito
Solução Gosign
CMS
TYPO3 (Enterprise) ou WordPress (focado em conteúdo)
Integração PIM
Akeneo, Pimcore, integração personalizada
Integração ERP
SAP, Microsoft Dynamics, API personalizada
Multilinguismo
TYPO3 nativo, até 30+ idiomas
Performance
Cloudflare CDN, Edge Caching, geração estática
Conversar sobre projeto industrial - 30 minutos, gratuito.
Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.
25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA
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.
Atualizado em: fevereiro de 2026
--- 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.
Situação inicial
A Pilot Gruppe precisava de uma infraestrutura de IA construída sobre o ambiente existente de Microsoft Azure. Requisitos principais:
A soberania de dados deve permanecer dentro da organização
Autenticação pelo Azure Entra ID existente (SSO)
Controle de acesso departamental - dados de RH apenas para RH
Múltiplos modelos de IA utilizáveis em paralelo
Conformidade com LGPD confirmada por avaliação independente antes do lançamento
Implementação
Arquitetura multi-modelo
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.
Controle de acesso via Azure Entra ID
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.
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.
Progressive Web App (PWA)
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.
Avaliação LGPD antes do lançamento
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).
Agentes de IA na plataforma n8n
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.
Resultado
Todos os dados permanecem no ambiente Azure da Pilot Gruppe - em conformidade com LGPD
A infraestrutura de TI e autenticação existentes são reutilizadas
Model-agnóstica: novos modelos integráveis sem alteração na arquitetura
Workspaces departamentais com Role-Based Access Control
Colaboradores criam de forma independente assistentes de IA e agentes
Compartilhamento de agentes entre departamentos controlado pela TI
Avaliação LGPD independente antes do lançamento
Tecnologia
Microsoft Azure (ambiente do cliente)
Azure Entra ID (SSO, RBAC)
n8n (orquestração de agentes)
Múltiplos LLMs (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)
PWA (Progressive Web App)
Contribuição da Gosign
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.
--- 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.
Agência de Mídia · 1.000 Colaboradores
pilot Agency Group
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.
A Gosign entregou uma infraestrutura self-hosted com residência de dados completa na UE, antes que outros fornecedores sequer tivessem priorizado o tema.
"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."
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ã (§203 StGB, BRAO, StBerG, WPO - regulamentações alemãs de sigilo profissional para advogados, consultores fiscais e auditores).
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.
"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."
Setor
Advocacia, Consultoria Fiscal, Auditoria
Colaboradores
100 (38 profissionais licenciados)
Localidades
Hamburgo, Leipzig
Foco
IA em conformidade com sigilo profissional, Decision Layer, trilha de auditoria
Empresa de logística comercial do norte da Alemanha
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.
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.
Setor
Logística Comercial
Colaboradores
500+
Localidade
Norte da Alemanha
Foco
Consultoria estratégica, suporte ao cliente com IA
--- 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.
Resumo - Agent Governance para RH
Agent Governance define quais decisões os agentes podem tomar, como as ações são documentadas e como as regras são versionadas.
RH deve liderar governance - não TI - porque limiares de escalação, definições de bias e propriedade de regras exigem expertise funcional.
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.
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.
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.
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.
eBook gratuito: IA em RH
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.
## 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/)
Agendar consultoria - 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.
Resumo - Agentes IA para empresas
Agentes IA executam processos, não apenas respondem perguntas. A diferença entre chatbot e agente é arquitetônica, não gradual.
A arquitetura corporativa do agente tem cinco camadas: interface do usuário, orquestração, modelo IA, integração de ferramentas (MCP) e Governance.
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.
Quatro requisitos de Governance são inegociáveis antes da produção: Decision Layer, Human-in-the-Loop, Audit Trail e Rollback.
Comece com um agente para um processo. A infraestrutura construída para o primeiro agente é a plataforma para cada um dos seguintes.
## 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.
Agende uma consulta. 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.
Em resumo - O ato de decisão
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?".
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.
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.
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.
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.
## 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"?
UMA “DECISÃO DE IA”
input: solicitação MA-4711
?
resultado: negado
1 resultado · 0 justificativas · não contestável ✗
13 MICRODECISÕES
input: solicitação MA-4711
01020304050607080910111213
Regra (10)IA (1)Humano (2)
13 atos · 13 justificativas · contestáveis uma a uma ✓
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:
Atestado recebido em 14.05.2026, 07:12. Caso processado em 54 segundos - decomposto em 13 microdecisões documentadas.
10 Regra
1
2 Humano
02
Cálculo dos 15 dias do empregador (Lei 8.213/91, art. 60, §3º)Regra
Salário integral de 14.06 a 28.06.2026
input: período do atestado 14-27.05 · dados cadastrais EMP_0x52a8
rule:Lei-8.213/91-art.60-§3º · v2026-01
06
Orientar requerimento ao INSS (auxílio por incapacidade temporária)Regra
A partir do 16º dia - empregado requer via Meu INSS, benefício B31
input: histórico de afastamentos, 12 meses (3 períodos)
rule:Lei 8.213/91 art. 59-63 · v2025-07
09
Marcar padrão de afastamentosIA 91%
Aviso ao RH: terceiro afastamento curto em seis meses
input: metadados de afastamento anonimizados - sem diagnóstico (LGPD art. 11)
model-reason:correspondência de padrão de afastamentos curtos repetidos · indicador, não decisão de pessoal
formalmente contestável · LGPD art. 20
13
Conversa de retorno ao trabalhoHumano
Plano de reintegração acordado
decided-by:analista de RH- 17.05.2026, 14:10
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:
01
Presentation Layer
Interfaces de usuário, gateways de prompts, portais de acesso para áreas de negócio e sindicato.
02
Orchestration Layer
Coordenação multiagente, roteamento de eventos, gestão de estado entre processos.
03
Agent Layer núcleo Gosign
Agentes Document, Workflow e Knowledge - a camada executora com julgamento de IA.
04
Decision Layer núcleo Gosign
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).
05
Governance Layer
Audit trail, registros assinados, controles cert-ready (EU AI Act art. 9/12/13/14 para negócios na UE, ISO 27001, NBC).
06
Model Layer
Registro de modelos, versionamento, calibração de confiança - agnóstico de modelo.
07
Integration Layer
Conectores para SAP, Workday, sistemas ERP - saídas prontas para lançamento.
## 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/)
Agendar reunião - 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.
Resumo - Cert-Ready by Design
Cert-Ready by Design significa que a prontidão para auditoria é um princípio arquitetônico, não um projeto de documentação retrospectivo.
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.
ISACA (2023) relata que organizações com monitoramento contínuo de controles reduzem o tempo de preparação para auditoria em até 65%.
O mapeamento de frameworks cobre ISA, NBC/CPC e conformidade fiscal - evidências falam a linguagem que auditores compreendem.
Resultado: a auditoria do processamento assistido por IA leva horas em vez de semanas, com evidências completas e à prova de manipulação.
## 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/)
Agendar reunião - 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.
Resumo - ChatGPT sem login: risco corporativo
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.
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.
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.
O valor real surge quando a interface de chat evolui para plataforma de agentes - processando documentos, orquestrando workflows, respondendo consultas de conhecimento.
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.
## 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.
Resumo - Artigo 5 de 6 da série DevOps Runbook
Claude Code apenas no servidor de auditoria
Modelo de três camadas
Custom Commands definem o escopo da revisão
Modo headless restrito a Read/Grep/Glob
Auditoria cron semanal mais revisões de PR
## 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.
Checklists de auditoria da série
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.
## 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.
Resumo - Comitê & AI Literacy
Projetos de IA fracassam na organização, não na tecnologia. O comitê e AI Literacy são os dois fatores decisivos.
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.
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.
Um regulamento interno se torna executável quando suas regras são implementadas como restrições técnicas no Decision Layer.
Programas de treinamento por função transformam obrigações de compliance em vantagens competitivas: funcionários informados usam IA de forma mais eficaz.
## 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/) |
---
Agendar reunião - 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.
Resumo - Participação dos trabalhadores como Constraint arquitetônico
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.
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.
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.
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.
Processo em quatro passos: analisar acordos existentes, elaborar catálogo de requisitos, implementar como controles no Decision Layer, conceder acesso ao Portal do Auditor.
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.
Requisito do acordo de empresa
Implementação no Decision Layer
Verificação
Sem avaliações de desempenho automatizadas
Regra Human-in-the-Loop (imposta)
Logs de escalação no Portal do Auditor
Relatório trimestral sobre decisões com IA
Geração automática de relatórios
Dashboard do portal com dados ao vivo
Parar IA ante suspeita de discriminação
Gatilho de monitoramento de viés
Log de alertas e histórico de incidentes
Todos os controles ativos e funcionais
Control_ID por requisito
Histórico de evidências por controle
## 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.
eBook gratuito: IA em RH
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.
## 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/)
Agendar reunião. 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.
Resumo - Contrato de operador para infraestrutura de IA
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.
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.
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.
Um checklist de 25 perguntas ajuda responsáveis de RH e compliance a verificar a prontidão do provedor de IA em sete categorias.
Isto não é assessoria jurídica - é uma bússola arquitetônica que revela lacunas de infraestrutura por trás das lacunas contratuais.
## 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.
Resumo - Custos reais da IA enterprise
Preços de tokens representam apenas 20 a 35% dos custos reais. Infraestrutura, governance e pessoal compõem os 65 a 80% restantes.
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.
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.
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.
## 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.
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
## 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.
Agendar reunião. 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.
Resumo - Decision Layer
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.
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.
Quatro componentes - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - garantem rastreabilidade, compliance e prontidão para auditoria.
Em decisões baseadas em regras e repetitivas, a IA comprovadamente supera o humano em consistência, resistência à fadiga e completude.
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.
[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.
Tipo de decisão
Velocidade
Auditabilidade
Nível de risco
Exemplo
Decisão humana
Baixa (minutos a dias)
Alta (revisão documentada)
Baixo (julgamento humano)
Planejamento de reintegração
Baseada em regras
Alta (instantânea)
Alta (regras versionadas)
Baixo (determinística)
Classificação salarial
IA autônoma
Alta (instantânea)
Alta (Audit Trail)
Médio (Confidence Routing)
Classificação de documentos
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/)
Agendar reunião - 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.
Resumo - Decision Layer para Payroll
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.
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.
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.
Casos rotineiros são processados de forma autônoma; exceções são escaladas para especialistas com contexto completo e valor de confiança.
A prontidão para auditoria se torna estrutural: cada caminho de decisão é documentado automaticamente do documento de origem à regra aplicada.
## 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.
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
## 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.
| 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 |
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/)
Agendar reunião - 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.
Resumo - Shadow AI e o Decision Layer
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.
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.
O Decision Layer separa análise de decisão: IA pode analisar, mas quem age é definido por microdecisão (humano, regras ou IA).
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.
Sem arquitetura governance-first, nem representantes dos trabalhadores, nem auditores, nem a diretoria aprovarão o escalamento da IA.
## 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/).
Agendar reunião. 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.
Resumo - Decision Layer vs. agentes enterprise
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.
Nem Joule nem Copilot oferecem mecanismos integrados para acordos coletivos, conformidade com AI Act ou caminhos de decisão auditáveis.
O Decision Layer é agnóstico em relação a modelo e agente - funciona com qualquer agente, incluindo modelos open source.
Empresas em ambientes regulados precisam de ambos: um agente para execução e um Decision Layer para governance.
Agentes são intercambiáveis. Governance é infraestrutura.
## 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/)
Agendar reunião - 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/).
Resumo - DeepSeek em uso enterprise
O DeepSeek R1 é open source (licença MIT) e pode rodar inteiramente self-hosted no Azure, GCP ou on-premise - sem vazamento de dados.
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 é.
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.
Uma arquitetura agnóstica de modelos previne o vendor lock-in: quando um modelo melhor surge, é integrado sem reconstrução.
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.
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.
Resumo - Portais Enterprise AI
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.
Cinco opções open source disponíveis: LobeChat, OpenWebUI, LibreChat, chatbot-ui e very-ai - cada uma adequada a diferentes requisitos de governance.
Detecção e anonimização de PII é o diferencial crítico para ambientes regulados onde dados de colaboradores entram em prompts de IA.
Gartner (2024) reporta que 55% das organizações com IA generativa não possuem um framework de governance para seu uso.
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.
## 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.
Agendar reunião - 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.
Resumo - EU AI Act 2026: status para empresas
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.
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.
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.
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.
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.
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.
Marco
Data
Status
Obrigações principais
Entrada em vigor
Agosto 2024
Ativo
Estrutura estabelecida
Práticas proibidas + AI Literacy
Fevereiro 2025
Ativo
Proibição Social Scoring, manipulação; obrigação de treinamento
Obrigações GPAI
Agosto 2025
Ativo
Transparência, rotulagem, inventário de governance
Sistemas High-Risk
2 de agosto de 2026 (adiamento para dez. 2027 acordado provisoriamente - Digital Omnibus)
Prazo vigente
Conformidade plena: gestão de riscos, governance de dados, Human Oversight
Disposições restantes
Agosto 2027
2027
Regras setoriais, categorias restantes
## 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.
Agendar reunião. 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.
Resumo - IA em RH é alto risco pelo EU AI Act
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.
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).
Seis requisitos obrigatórios: gestão de riscos, governance de dados, obrigações de registro, transparência, supervisão humana e precisão/robustez.
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.
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).
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).
Artigo EU AI Act
Requisito
Implementação no Decision Layer
Art. 9
Sistema de gestão de riscos
Confidence Routing com limiares configuráveis
Art. 10
Governance de dados
Conjuntos de regras versionados com datas de vigência
Art. 12
Obrigações de registro
Audit Trail imutável por decisão
Art. 13
Transparência
Portal do Auditor com caminho de decisão completo
Art. 14
Supervisão humana
Human-in-the-Loop imposto para tipos definidos
Art. 15
Precisão e robustez
Monitoramento de viés e design model-agnostic
Art. 86
Direito à explicação da decisão individual
Ato de decisão por microdecisão com caminho de contestação (alinhado à LGPD art. 20)
## 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.
eBook gratuito: IA em RH
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.
## 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/)
Agendar reunião - 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.
Resumo - Obrigações do EU AI Act para RH
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.
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.
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.
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.
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).
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.
Processo de RH
Classificação EU AI Act
Requisito principal
Triagem de CV / Recrutamento
Alto risco (Anexo III)
Monitoramento de viés, Audit Trail
Avaliação de desempenho
Alto risco (Anexo III)
Supervisão humana, transparência
Decisões de promoção
Alto risco (Anexo III)
Explicabilidade, Human-in-the-Loop
Planejamento de escalas (com dados pessoais)
Potencialmente alto risco
Avaliação de riscos, governance de dados
Compliance Knowledge Agent
Risco limitado
Obrigação de transparência
## 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/)
Agendar reunião - 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.*
Resumo - Accountability de IA é universal
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.
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.
Um algoritmo enviesado escala a discriminação para 50.000 decisões simultaneamente, comparado a cerca de 50 por ano de um gestor enviesado.
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).
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.
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.
Região
Legislação principal
Explicabilidade exigida
Decisões de RH cobertas
UE
EU AI Act, RGPD Art. 22
Sim (vinculante)
Sim (Anexo III alto risco)
Brasil
LGPD Art. 20, CLT, PL 2338/2023
Sim (direito a explicação)
Sim (Justiça do Trabalho ativa)
EUA
Title VII, NYC Local Law 144
Sim (antidiscriminação)
Sim (decisões de emprego)
China
Algorithmic Provisions 2022
Sim (transparência exigida)
Sim (decisões algorítmicas)
Argentina
Ley de Contrato de Trabajo
Sim (proteção trabalhista)
Sim (discriminação trabalhista)
## Por que o RH é o Ground Zero
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
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
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.
Resumo - Estratégia de hosting IA para enterprise
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.
A arquitetura híbrida roteia requisições por sensibilidade de dados: 60-70% cloud, 25-35% IaaS europeu, 5-10% on-premises.
Gartner (2025) estima que 40% das grandes empresas operarão arquiteturas híbridas de hosting IA até 2027, ante menos de 10% em 2024.
Modelos open source self-hosted (gpt-oss-120b) rodam em uma única GPU por aprox. 1.200 EUR por mês em provedores europeus.
Custos totais com estratégia híbrida ficam 30-40% abaixo de uma estratégia pura de Cloud API, com maior soberania de dados.
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
eBook gratuito: Infraestrutura de IA
Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.
## 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.
Agende uma conversa - 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.
Resumo - Arquitetura Human-in-the-Loop
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.
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.
O EU AI Act exige supervisão humana efetiva para sistemas de IA de alto risco - processos de RH se enquadram explicitamente nessa categoria.
Acordos de empresa se tornam restrições técnicas no Decision Layer que o sistema não pode contornar.
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.
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/)
Agendar reunião - 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.
Resumo - Dashboard de Governança IA
Um dashboard de governança IA é a camada de apresentação dos dados do Decision Layer - não uma ferramenta de monitoramento independente.
Exibe atividades dos agentes, Audit Trail, desempenho de modelos e versões de regras em tempo real.
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.
Gartner (2024) prevê que até 2026, organizações com frameworks de governança IA terão 40% menos incidentes de compliance relacionados a IA.
Sem dashboard, ninguém na organização consegue verificar o que os agentes de IA realmente fazem.
## 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.
Componente
Finalidade
Fonte de dados
Log de atividades dos agentes
Rastrear cada ação do agente em tempo real
Entradas de protocolo do Decision Layer
Visualizador de Audit Trail
Registros de decisão pesquisáveis e exportáveis
Registros de auditoria do Decision Layer
Monitor de modelos
Comparar desempenho e custos de LLM
Métricas de inferência por modelo
Linha do tempo de versões de regras
Rastrear alterações com responsabilidade atribuída
Repositório de regras versionado
Dashboard de escalação
Monitorar taxas de Human-in-the-Loop
Eventos de escalação HITL
## 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.
Em resumo - IA open-source self-hosted para enterprise brasileira 2026
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).
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.
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.
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.
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.
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.
## 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).
Ponto de cruzamento TCO: self-hosted vs API cloud - 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.
## 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.
Resumo - Infraestrutura AI Enterprise 2026
Oito decisões estratégicas que todo CTO ou CIO precisa tomar em 90 dias para implantar IA em escala enterprise.
Seleção de modelo, nível de hosting, portal AI, RAG, agentes, Decision Layer, compliance e orquestração formam o stack completo.
A arquitetura híbrida de hosting - roteamento por sensibilidade de dados entre cloud, IaaS europeu e on-premises - se tornou o padrão.
IDC (2025) projeta gastos mundiais em infraestrutura de IA de 154 bilhões de USD até 2027, ante 76 bilhões em 2024.
Um plano de ação concreto de 90 dias transforma projetos-piloto em infraestrutura produtiva com governance integrada desde o início.
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
Decisão
Tema
Pergunta-chave
1
Seleção de modelo IA
Qual modelo para qual tarefa? Routing model-agnostic.
2
Estratégia de hosting
EU SaaS, data center europeu ou Self-Hosted?
3
Enterprise AI Portal
Interface controlada com SSO, Audit Trail, proteção PII.
4
RAG & Document Intelligence
Como tornar o conhecimento corporativo acessível para IA?
5
AI Agents
De chatbot a agente autônomo multi-etapa.
6
Decision Layer
Separar análise IA de decisões de negócio.
7
Custos e EU AI Act
TCO e obrigações regulatórias desde agosto 2025.
8
Orquestração de agentes
n8n, Camunda ou Temporal para workflows produtivos.
eBook gratuito: Infraestrutura de IA
Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.
## 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.
Agendar consultoria. 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.
Resumo - Infraestrutura IA vs. hype de ferramentas
ChatGPT, CoPilot e Gemini são ferramentas de IA - não infraestrutura enterprise. Faltam Audit Trail, isolamento por cliente e integração sistêmica.
A infraestrutura IA enterprise é composta por sete camadas: Presentation, Orchestration, Agent, Decision, Model, Integration e Infrastructure.
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.
Uma arquitetura model-agnostic previne vendor lock-in e mantém os modelos substituíveis - Claude, GPT, Gemini, Llama, Mistral.
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.
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
Capacidade
Ferramenta IA (ChatGPT)
Infraestrutura IA
Audit Trail
Não
Protocolo de decisão imutável
Isolamento por cliente
Não
Row-Level Security, separação de workspaces
Integração ERP
Não
SAP, TOTVS, Workday via APIs
Regras versionadas
Não
Específicas por cliente, versionadas
Human-in-the-Loop
Não
Imposto pela arquitetura
Independência de modelo
Vinculado a um provedor
Routing model-agnostic
Camada de governance
Não disponível
Transversal a todas as camadas
## 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/)
Agendar reunião - 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.
Resumo - Integração de IA na TI existente
Infraestrutura IA é uma camada de integração sobre os sistemas existentes - SAP, Workday e ambientes cloud permanecem inalterados.
Quatro camadas arquitetônicas: conectividade com sistemas, orquestração, Decision Layer e interface do usuário.
Agentes se comunicam via APIs padrão (RFC, OData, REST) - sem acesso direto a banco de dados, sem interfaces proprietárias.
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.
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.
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
Camada
Função
Tecnologia
Conectividade
Leitura/escrita em sistemas de origem
SAP RFC/OData, Workday REST, TOTVS API, Microsoft Graph
## 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.
Resumo - Integração de IA em sistemas enterprise
AI Agents ampliam sistemas existentes (SAP, TOTVS, Workday) em vez de substituí-los - o agente é uma camada de integração externa.
O Integration Layer desacopla a lógica do agente do sistema-alvo: quando o ERP muda, apenas a camada de exportação muda.
A lógica de negócio (Decision Layer) é separada arquitetonicamente do formato de exportação (Integration Layer), reduzindo o esforço de migração.
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.
Agentes utilizam autenticação, ambiente de nuvem, políticas de segurança e monitoramento existentes - sem sistema paralelo.
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
Sistema-alvo
Método de integração
Escopo de dados
SAP FI/CO, S/4HANA
RFC, REST API, SAP BTP
Propostas de lançamento, lógica de centros de custo
TOTVS Protheus/Datasul
APIs TOTVS, módulos fiscais
Lançamentos, planos de contas, SPED
Workday
Workday REST API
Dados RH, folha de pagamento, estrutura org.
SuccessFactors
SAP SuccessFactors API
Dados funcionários, desempenho, remuneração
Microsoft Graph
Graph API
SharePoint, Teams, Outlook
## 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/)
Agendar reunião - 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.
Resumo - LLM Self-Hosting para Enterprise
O self-hosting mantém todos os dados na rede corporativa - sem processamento por terceiros, controle total sobre modelo, dados e inferência.
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.
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.
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.
Gartner (2024) prevê que 45% das implantações de IA em setores regulados operarão em infraestrutura privada até 2027 - ante 20% em 2023.
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.
Critério
Self-Hosted
Cloud API
Data Residency
Controle total, dados permanecem on-premise
Depende do provedor, regiões UE disponíveis
Escolha de modelo
Apenas open source (Llama, Mistral, DeepSeek)
Proprietários + open source via API
Custo em escala
Menor (custo GPU fixo, sem taxas por token)
Maior (preço por token escala linearmente)
Esforço operacional
Alto (gestão GPU, atualizações, HA)
Baixo (gerenciado pelo provedor)
Latência
Baixa (rede local)
Variável (depende da rede)
eBook gratuito: Infraestrutura de IA
Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.
## 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/)
Agendar reunião - 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.
Resumo - Arquitetura modelo-agnóstica
Construir sobre um único fornecedor de LLM cria dependência perigosa: preços mudam, APIs são reestruturadas, modelos são descontinuados sem aviso.
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.
O roteamento multi-modelo atribui modelos econômicos a tarefas simples e flagships a raciocínio complexo, economizando 40-60% em custos de tokens.
Modelos self-hosted processam dados sensíveis enquanto Cloud APIs atendem requisições não críticas - governado pelo Decision Layer.
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.
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/).
Agendar reunião - 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.
Em resumo - Stack agêntico para a empresa brasileira em 2026
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.
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).
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.
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.
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.
## 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.
Perfil de modelo em seis dimensões enterprise - 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.
## 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
Resumo - Artigo 2 de 6 da série DevOps Runbook
Next.js como container separado isolado do Supabase
Chave service_role em apenas um arquivo
Middleware com getUser() em cada requisição
Verificação de ownership antes de mutações
Rate limiting em endpoints de autenticação
## Í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.
Download da checklist de auditoria
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.
claude -p "$(cat claude-check-artikel-2-nextjs-br.md)" --allowedTools Read,Grep,Glob,Bash
## Í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.
Resumo - Agentes de IA na empresa
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).
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).
McKinsey (2024) estima que agentes de IA podem automatizar até 30% das horas de trabalho na maioria das ocupações até 2030.
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.
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.
## 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/)
Agendar reunião - 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.
Resumo - Plataformas de orquestração de agentes
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.
Trigger.dev é a recomendação padrão: TypeScript-nativo, Durable Execution, licença Apache 2.0, auto-hospedável, produtivo em duas semanas.
Camunda complementa quando diagramas BPMN formais são exigidos por representantes dos trabalhadores ou auditores.
Cinco das seis plataformas suportam self-hosting - Make (apenas SaaS) é a exceção.
A escolha da plataforma é uma decisão arquitetônica que afeta governance, compliance e time-to-production.
## 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?**
Agendar reunião. 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.
Resumo - Anonimização de PII para IA Empresarial
A pseudonimização roundtrip substitui PII por pseudônimos consistentes antes do processamento pelo LLM, e reinsere os dados reais na saída.
O Decision Layer governa quais categorias de PII são detectadas por processo (RH, finanças, compliance) por meio de conjuntos de regras versionados.
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.
O Confidence Routing escala entidades ambíguas para um humano; identificadores implícitos requerem regras de contexto no conjunto de regras.
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).
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/)
Agendar reunião - 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.
Visão geral - Por que treinamento é a arquitetura errada
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%.[1]
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.[10]
A alternativa: conjunto de regras (versionado), contexto (por decisão), Decision Layer (pessoa/regra/AI por Micro-Decision).
Agentes configurados são modelo-agnósticos: troca de modelo Foundation sem alterar o conjunto de regras. Sem lock-in, sem retreinamento.
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.[9]
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.
De treinamento a configuração
2018 - 2020
Treinamento é obrigatório
BERT, GPT-2. 110M - 1,5B parâmetros.
Duração: semanas
Custo: $10 000 - $100 000
Requisito: cluster GPU
2021 - 2023
Treinamento se torna opcional
GPT-3/3.5. 175B parâmetros.
Duração: dias
Custo: $1000 - $10 000
Requisito: GPU necessária
2024
Treinamento ou prompting?
GPT-4o, Claude 3.5. Multimodal.
Duração: horas
Custo: $10 - $100
Requisito: API-Call
2025 - 2026
Configuração é suficiente
GPT-5.5, Claude Opus 4.7. Reasoning.
Duração: minutos
Custo: $10 - $100
Requisito: API-Call
Kumar Gauraw resume com precisão: "A maioria recorre ao Fine-Tuning cedo demais."[5] 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).[10] 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
Arquitetura A
Modelo treinado
"Por que esta decisão?"
"O modelo aprendeu" - Black Box
Não explicável
"Mudança na legislação?"
Retreinamento. 2 - 4 semanas, $5000 - $20 000
Caro e lento
"O afetado pode contestar?"
Contra o quê? Contra pesos?
Não contestável
"Novo modelo LLM disponível?"
Novo treinamento necessário. Semanas, lock-in.
Dependência do fornecedor
"Conforme ao EU AI Act?"
Art. 13: falta transparência. Art. 14: intervenção = substituir modelo. Art. 86: explicação não possível.
Problemático
Lock-in: sim | Auditoria: difícil | EU AI Act: problemático
Arquitetura B
Agente configurado
"Por que esta decisão?"
"§9 EStG v2026-01, ausência 14h15min" (lei fiscal alemã - regras análogas em cada jurisdição)
Regra, versão, contexto documentados
"Mudança na legislação?"
Atualizar regra. Efeito imediato, $0.
Versionado e auditável
"O afetado pode contestar?"
"O café da manhã não estava incluído." O responsável verifica.
Contestável com registro de decisão
"Novo modelo LLM disponível?"
O conjunto de regras permanece. 0 esforço, sem lock-in.
Modelo-agnóstico
"Conforme ao EU AI Act?"
Registro de decisão por Micro-Decision. Sobrescrever regra, não substituir modelo.
Conforme by Design
Lock-in: não | Auditoria: by Design | EU AI Act: conforme
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.[1] Sem Fine-Tuning. Sem treinamento. Apenas o conjunto de regras como contexto.
O resultado:
Fatura jurídica: conforme às regras ou não?
Better Bill GPT, Whitehouse et al. (abril 2025). Peer-reviewed. O LLM recebeu o conjunto de regras como contexto, sem Fine-Tuning.[1]
Precisão geral
LLM (sem treinamento)
92%
Juristas experientes
72%
Classificação de itens individuais (F-Score)
LLM (sem treinamento)
81%
Melhor grupo humano
43%
Tempo por fatura
LLM
3,6 seg.
Juristas
~250 seg.
Custo por fatura
LLM
< $0,01
Juristas
$4,27
Redução de custos: 99,97%.[4] Mecanismo transferível para qualquer tarefa de compliance baseada em regras.
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.[1]
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.
Dimensão
Modelo treinado
Agente configurado
Mudança de regras
Retreinamento (semanas, $5k - $20k)
Atualização do conjunto de regras (minutos, $0)
Explicabilidade
"O modelo aprendeu" (Black Box)
Regra + versão + contexto (registro de decisão)
Contestabilidade
Não possível (sem registro de decisão)
Sim (o afetado vê a regra e pode contestar)
Troca de modelo
Novo treinamento necessário (lock-in)
0 esforço (modelo-agnóstico)
Audit Trail
Entrada + saída (sem fundamentação)
Entrada + regra + versão + confiança + resultado
EU AI Act (ago. 2026)
Art. 13, 14, 86: problemático
Art. 13, 14, 86: conforme by Design
Break-Even Fine-Tuning
A partir de ~35 000 consultas/mês[6]
Economicamente viável de imediato
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.[6] 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%.[11] 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/).
Micro-Decision na prática
Prestação de contas de viagem: jornada de 8 horas, viagem nacional, hotel com café da manhã
#1Data da viagem e duração da ausênciaContextoInput: comprovantes
#2Calcular diária de viagemConjunto de regras§9 EStG v2026-01
#3Aplicar dedução por café da manhãConjunto de regras§9 Abs. 4a S. 8 EStG
#5A despesa de representação é "razoável"?PessoaCritério, o responsável verifica
#6Criar lançamento contábil conforme normativaConjunto de regrasNormativa contábil, versionada
Cada um desses passos tem um tipo fixo: conjunto de regras (determinístico), AI (probabilístico, com limiar de confiança) ou pessoa (critério). Quando §9 EStG muda, a regra é atualizada. Sem retreinamento. Sem novo modelo.
## 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.
Camada 3Decision Layer
Micro-DecisionsPessoa / Regras / AIRegistro de decisãoAudit Trail
Camada 2Conjunto de regras (versionado, intercambiável)
Legislação tributáriaRegulamentosNormativa contábilConvenção coletivaAcordo coletivoEU AI Act
Camada 1Foundation Model (intercambiável)
ClaudeGPTLlamaMistralGemini
↑
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.
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.[7] Mas 62% dos contadores se preocupam com erros da AI.[8] 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.[10]
### 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.[6] 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.[9] 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.[10]
## 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.
---
Referências
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.
Better Bill GPT, Whitehouse et al. (abril 2025). F-Score na classificação de itens individuais: LLM 81% vs. melhor grupo humano 43%.
Better Bill GPT, Whitehouse et al. (abril 2025). Tempo de processamento por fatura: LLM 3,6 segundos vs. juristas experientes 194 a 316 segundos.
Better Bill GPT, Whitehouse et al. (abril 2025). Redução de custos na Legal Invoice Review: 99,97% ($4,27 vs. <$0,01 por fatura).
Kumar Gauraw (março 2026). "A maioria recorre ao Fine-Tuning cedo demais."
Chauhan et al., Journal of Information Systems Engineering (2025). Break-Even Fine-Tuning vs. Prompting: ~35 000 consultas por mês.
MIT/Stanford, Choi & Xie (agosto 2025). AI reduz o fechamento mensal em média 7,5 dias.
MIT/Stanford, Choi & Xie (agosto 2025). 62% dos contadores expressam preocupação sobre erros da AI em processos financeiros.
Gartner (junho 2025). Projeção: mais de 40% dos projetos de Agentic AI fracassarão até 2027.
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.
IBM (2024). RAG reduz erros factuais nas saídas de LLM em até 50%.
--- 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.
Resumo - Por que projetos de IA fracassam
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.
O AI-Paradox: empresas adotam IA amplamente, mas apenas uma fração obtém resultados mensuráveis - falta a arquitetura de decisões.
MIT Sloan Management Review (2024) constatou que 70% das iniciativas de IA corporativa não conseguem sair do piloto para a produção.
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.
O Decision Layer decompõe processos de negócio em passos de decisão documentados - humano, regras ou IA - transformando experimentos em sistemas produtivos.
## 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 |
eBook gratuito: IA em RH
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.
## 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.
Resumo - RAG & Document Intelligence
RAG conecta modelos de linguagem aos seus documentos corporativos - sem treinamento, sem vazamento de dados. Documentos permanecem na sua infraestrutura.
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.
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.
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.
RAG se integra ao portal Enterprise AI para que cada departamento acesse apenas sua base de conhecimento autorizada.
## 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.
Agende uma consulta. 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.
Resumo - Medir o ROI de enterprise AI
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.
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.
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.
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.
Comece com um processo, um agent, e meça os KPIs após 4 a 6 semanas. A diferença é o ROI.
## 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.
| 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 |
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
## 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
Resumo - Artigo 6 de 6 da série DevOps Runbook
Um único arquivo YAML define o estado desejado do stack
Verificações automatizadas diárias
Análise semanal do Claude
Gate de deploy bloqueia em violações críticas
Documento vivo atualizado com mudanças no stack
## 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**.
Checklists de auditoria da série
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.
## 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.
Resumo - Segurança de dados em IA corporativa
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.
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).
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.
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.
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.
## 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/)
Agendar uma reunião - 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.
Resumo - Série DevOps Runbook
Seis runbooks cobrem o stack self-hosted completo: Supabase, Next.js, Edge Functions, Trigger.dev, auditorias Claude Code e Security Baseline.
Cada artigo contém implementações concretas com código real, condições verificáveis e checklists do Claude Code para download.
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.
Público-alvo: engenheiros DevOps, CTOs, engenheiros de segurança e desenvolvedores que constroem sobre Supabase e Next.js.
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.
## 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.
Resumo - Shadow AI Governance
Shadow AI significa que colaboradores usam ferramentas de IA externas sem conhecimento da TI, enviando dados da empresa para sistemas não controlados.
Proibições não funcionam - colaboradores usam dispositivos pessoais e ferramentas alternativas. A proibição gera evasão descontrolada.
PwC (2024) constatou que 54% das empresas têm colaboradores usando ferramentas de IA generativa sem aprovação formal da organização.
A solução é infraestrutura controlada: interface de IA empresarial, Model Routing, protocolo de uso e Audit Trail.
Três fases: inventário do uso atual, implantação de infraestrutura controlada, depois agentes especializados para casos de uso frequentes.
## 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/)
Agendar reunião - 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.
Resumo - Artigo 3 de 6 da série DevOps Runbook
Edge Functions apenas como pontos de integração (webhooks), não segundo backend
Verificação obrigatória de assinaturas de webhooks
CORS configurado explicitamente (sem wildcard)
Validação de entrada com Zod
Tarefas de longa duração delegadas ao Trigger.dev
## 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 {
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) {
console.log(`Checkout completed: ${session.id}`)
}
async function handlePaymentFailed(invoice: Record) {
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 {
// GitHub usa sha256=
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.
Download da checklist de auditoria
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.
claude -p "$(cat claude-check-artikel-3-edge-functions-br.md)" --allowedTools Read,Grep,Glob,Bash
## 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.
Resumo - Artigo 1 de 6 da série DevOps Runbook
Arquitetura de dois servidores separa produção e auditoria
## 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 &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.
Download da checklist de auditoria
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.
claude -p "$(cat claude-check-artikel-1-supabase-br.md)" --allowedTools Read,Grep,Glob,Bash
## 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.
Resumo - ROI da automatização de despesas de viagem
O processamento manual custa 58 USD por recibo com taxa de erro de 19% e 52 USD por correção (GBTA Foundation).
Com 100.000 transações por ano, só o processamento gera quase 7 milhões USD - antes das despesas de viagem reais.
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).
A abordagem Decision Layer alcança 85 a 95% de processamento zero-touch com regras versionadas e auditáveis para cada micro-decisão.
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.
## 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)
| 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** |
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)
| 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** |
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)
| 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** |
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.
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
## 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:
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.
Resumo - Limites do SAP Concur em despesas de viagem corporativas
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).
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.
Convenções coletivas, cruzamentos de fronteira multinacionais e operações irregulares ficam fora do modelo de dados de qualquer ferramenta padrão de despesas.
O Decision Layer atua como camada de governance sobre o SAP Concur - regras versionadas, cálculo determinístico, Audit Trail sem lacunas.
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.
## 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.
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
## 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:
| 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** |
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:
| 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 |
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:
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.
Resumo - Três tipos de decisões
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.
IA autônoma não é a categoria para coisas triviais - é para decisões onde consistência, resistência à fadiga e exaustividade superam a discricionariedade.
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.
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.
Este framework torna a argumentação transparente para o comitê: IA decide onde a qualidade exige, humano decide onde a discricionariedade exige.
[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/)
Agendar reunião - 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.
Resumo - Artigo 4 de 6 da série DevOps Runbook
Trigger.dev como stack Docker separado com seu próprio PostgreSQL
Cada task precisa de maxDuration, concurrencyLimit e configuração de retry
Chaves de idempotência em chamadas de API externas
Acesso ao banco de dados limitado aos campos necessários
Logger do Trigger.dev em vez de console.log
## 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(
'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(
'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.
Download da checklist de auditoria
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.
claude -p "$(cat claude-check-artikel-4-trigger-dev-br.md)" --allowedTools Read,Grep,Glob,Bash
## 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.
Resumo - 25 anos de pesquisa sobre Pair Programming
Pares precisam de apenas 15% mais tempo - não o dobro - enquanto produzem 15-60% menos defeitos (Williams & Kessler, 2000; Arisholm et al., 2007).
Tarefas complexas são concluídas 29% mais rápido em pares, e o onboarding acelera 30-50% graças à transferência de conhecimento.
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.
Na era da IA, Pair Programming combate o isolamento profissional - 68% dos desenvolvedores relatam dias sem qualquer interação com a equipe (Microsoft, 2024).
Cálculo modelo enterprise: um projeto com 10 desenvolvedores economiza aproximadamente 345.000 EUR líquidos por ano em custos de defeitos e conhecimento.
## 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% [1]
- **15-60%** menos defeitos no código [1][4]
- **29%** mais rápido na conclusão de tarefas complexas [2]
- **30-50%** mais rápido no onboarding de novos membros da equipe [1]
- **95%** dos participantes de pairing relatam maior satisfação [2]
- **48%** menos linhas de código para a mesma funcionalidade [1]
- **30x** custos mais altos quando bugs são encontrados em produção [6]
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
Estudo
n
KPI
Resultado
Williams & Kessler (2000) [1]
41
Testes aprovados na primeira vez
+15% vs. solo
Williams & Kessler (2000) [1]
41
Densidade de defeitos
significativamente menor
Nosek (1998) [2]
15
Correção funcional
maior em pares
Nosek (1998) [2]
15
Legibilidade do código
maior em pares
Arisholm et al. (2007) [4]
295
Taxa de erros (tarefas complexas)
-60% vs. solo
Arisholm et al. (2007) [4]
295
Taxa de erros (tarefas simples)
marginal
Dyba et al. (2007) [5]
18 estudos
Qualidade geral do código
melhora estatisticamente significativa
Jensen (2003) [16]
120
Defeitos pós-aceitação
-40%
Padberg & Mueller (2003) [17]
Simulação
Defeitos pós-release
-20 a -40%
### Esforço temporal e produtividade
| Estudo | n | KPI | Resultado |
|--------|---|-----|-----------|
| Williams & Kessler (2000) [1] | 41 | Tempo total de desenvolvimento | **+15%** (não +100%) |
| Nosek (1998) [2] | 15 | Tempo decorrido (tarefa complexa) | **-29%** mais rápido |
| Arisholm et al. (2007) [4] | 295 | Esforço (tarefas simples) | **+84%** |
| Arisholm et al. (2007) [4] | 295 | Esforço (tarefas complexas) | **+18%** |
| Cockburn & Williams (2001) [3] | Revisão | Ponto de equilíbrio na redução de defeitos | **a partir de 3-5%** |
| Lui & Chan (2006) [18] | 40 | Throughput de tarefas | **+43%** vs. solo |
### Satisfação e dinâmica de equipe
| Estudo | n | KPI | Resultado |
|--------|---|-----|-----------|
| Nosek (1998) [2] | 15 | Satisfação com o resultado | **+95%** em pares |
| Williams et al. (2000) [1] | 41 | Recomendaria a colegas | **96%** trabalhariam em par novamente |
| Begel & Nagappan (2008) [19] | 106 | Satisfação com pairing (Microsoft) | **65%** satisfeitos |
| Begel & Nagappan (2008) [19] | 106 | Percebem melhora de qualidade (Microsoft) | **74%** |
### Eficiência do código
| Estudo | KPI | Resultado |
|--------|-----|-----------|
| Williams & Kessler (2000) [1] | Linhas de código (mesma funcionalidade) | **-48%** menos linhas |
| Mueller (2004) [20] | 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 [10] 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) [9]. 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) [21]: **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 [19]. 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 [19].
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 [22] 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" [9].
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 [2]. Flow não é a única receita para um bom trabalho. Shared Focus é a variante mais sustentável.
### "Code reviews são suficientes"
Fagan (1976) [14] mostrou: code reviews formais detectam **60-70% dos defeitos**. Parece bom. Pair Programming detecta **85-95%** [1]. 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) [23]. 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 [21] 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 [1]. 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) [7]
Toda pessoa tem uma capacidade limitada para processamento simultâneo de informações na memória de trabalho. Miller (1956) [8] 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 [17]. Não porque são mais inteligentes. Mas porque sua capacidade cognitiva combinada é maior.
### Efeito da verbalização (Chi et al., 1989) [11]
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%** [11].
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) [9]
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 [10]: a presença de um observador competente melhora o desempenho em tarefas bem dominadas em **15-20%**.
### Working Memory Complement (Flor & Hutchins, 1991) [24]
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) [12]
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)** [13]: Psychological Safety foi o **preditor n.1** de desempenho da equipe - mais importante que estrutura, clareza, significado ou confiabilidade
- **Edmondson (1999)** [12]: equipes com alto Psychological Safety **reportaram 70% mais erros** e puderam corrigi-los mais rapidamente
- **Rozovsky (2015)** [13]: 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 [15]
- **Custo de re-onboarding**: **6-12 meses** até um novo desenvolvedor ser produtivo em um projeto enterprise, **3-6 meses** com pair onboarding [1]
- **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 [1]
- **75% dos pares de onboarding** sentem-se "prontos para trabalho independente" após 2 semanas vs. **25% com onboarding solo** [21]
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) [25]: 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** [4] - aqui pairing raramente compensa
- Tarefas médias: **+15% de esforço** [1]
- Tarefas complexas: **+18% de esforço** com simultaneamente **-60% de defeitos** [4]
- Tempo decorrido (tarefa complexa): **-29%** mais rápido [2]
Pares descartam abordagens ruins **4x mais rápido** porque o navegador reconhece o erro de pensamento antes [18].
### Erro 2: Os custos de defeitos são ignorados
A curva de escalação de custos segundo Boehm e Basili (2001) [6]:
| 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)** [26] 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% | [14][1] |
| Tempo até detecção | Horas a dias | Segundos | Estrutural |
| Perda de contexto | Alta | Zero | [23] |
| Mal-entendidos no review | 60% (revisor interpreta mal a intenção) | 0% | [23] |
| 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) | [24] |
Bacchelli e Bird (2013) [23] 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 [27]: 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) [28] 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** [28]
- 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 [12]
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 [15]
- **Trabalho duplicado**: sem visibilidade do trabalho dos outros, **15-25% das funcionalidades são implementadas de forma redundante** (Herbsleb & Grinter, 1999) [29]
- **Perda de qualidade**: desenvolvedores que se sentem socialmente isolados mostram **33% mais defeitos** do que membros integrados da equipe (Begel & Nagappan, 2008) [19]
- **Burnout**: isolamento profissional é um dos preditores mais fortes de burnout entre trabalhadores do conhecimento (Maslach & Leiter, 2016) [30]
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 [4].
**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% | [1] |
| Tempo decorrido (complexo) | Base | -29% | [2] |
| Densidade de defeitos | Base | -15 a -60% | [1][4] |
| Linhas de código (mesma função) | Base | -48% | [1] |
| Testes aprovados na primeira vez | Base | +15% | [1] |
| Duração do onboarding | 3-6 meses | 1,5-3 meses | [1] |
| Satisfação | Base | +95% | [2] |
| Parearia novamente | n/a | 96% | [1] |
| Bus factor | 1 | Mínimo 2 | Estrutural |
| Defeitos pós-release | Base | -20 a -40% | [17] |
| Detecção de defeitos (críticos) | 90% | 99% | Estatístico |
| Custo por defeito (produção) | 30x codificação | Evitado | [6] |
| Tempo espera PR review | 4-24h | 0 | Estrutural |
| Mal-entendidos code review | 60% | 0% | [23] |
## 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 [1]. 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
**[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.
--- 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.
Resumo
"Automatizar o processo" fracassa. Classificar pontos de decisão individuais constrói uma arquitetura auditável.
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.
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.
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.
Contestabilidade é arquitetura, não anexo de compliance. Quem a parafusa depois não tem IA auditável - independentemente da qualidade do modelo.
## 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 de segurança no Brasil?
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.
O que a Gosign verifica em uma auditoria de segurança web
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.
Monitoramento contínuo
Monitoramento constante de CMS, extensions e configuração do servidor. Notificação imediata em caso de novas vulnerabilidades.
Fortalecimento & implementação
A Gosign implementa as medidas recomendadas: headers CSP, configuração TLS, setup de WAF, fortalecimento do CMS.
Documentação para auditorias
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.
Verificar a segurança do seu site - 30 minutos, gratuito.
Analisamos seu site quanto a vulnerabilidades de segurança, sem compromisso.
25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA
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.
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.
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.
eBook gratuito: IA em Finanças
Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.
O Finance Agent não é uma ferramenta OCR. É um sistema de Decision Automation que decide com base em conjuntos de regras versionados.
1. Ler e compreender documentos - com compreensão linguística real
2. Avaliar profissionalmente - conta, centro de custo, classificação fiscal
3. Decidir - O Decision Layer roteia: autônomo com alta confiança, humano para exceções
4. Documentar - Cada micro-decisão gera um registro completo
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
Conjuntos de Regras
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.
Cert-Ready by Design
Portal de Auditor: Status em tempo real de todos os controles com drill-down.
Registro por documento: Rota de decisão completa, não apenas resultado.
Mapeamento de frameworks: ISA, PS 951, IDW, GoB/GoBD (padrão GoBD alemão de arquivamento fiscal). Parte da nossa abordagem Governance by Design.
Lógica contábil separada de exportação. Mudança de sistema destino muda a exportação - não o agente.
TOTVS
Propostas em formato TOTVS, conforme normas contábeis brasileiras (CPC/CFC).
SAP FI/CO
Propostas em formato SAP, centros de custo e lucro.
finAPI / Banking
Processamento automático de extratos bancários.
Grupos Alvo
Firmas de auditoria e contabilidade: Consistência entre centenas de clientes.
Centros de serviços compartilhados: 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.
Empresas com contabilidade interna: Menos contabilizações corretivas, documentação completa.
Impacto de Negócio
Reduzir contabilizações corretivas mediante aplicação consistente.
Encurtar tempos de processamento com automação de rotina.
Reduzir risco de auditoria com documentação completa.
Tornar regras explícitas em vez de armazenadas em mentes individuais.
Escalar sem aumento proporcional de pessoal.
Aprofundamento no Agent Briefing (Revista Gosign)
Nossa série de artigos para decisores que automatizam processos financeiros com AI Agents.
--- 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.
Visão geral
4-6 semanas
Da descoberta ao agente produtivo em sua infraestrutura
Código-fonte completo
Código, prompts, conjuntos de regras, documentação - acesso completo e direito de uso permanente
Sem SaaS
Sem taxas mensais. Sem vendor lock-in. Operação autônoma possível.
Decision Layer
Cada agente com audit trail, Human-in-the-Loop e versionamento de conjuntos de regras
Agnóstico de modelos
Claude, ChatGPT, Gemini, Llama - intercambiáveis sem alteração de código
Estratégia de saída
Treinamento, documentação, transferência. Totalmente autônomo após 12-18 meses.
Três fases até o agente produtivo
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.
Fase 1 - Semana 1
Discover
Análise do processo com sua equipe especializada
Identificar e formalizar conjuntos de regras
Mapear pontos de decisão
Design do Decision Layer
Esclarecer paisagem de sistemas e integrações
Resultado: Blueprint do processo com matriz de decisão
Fase 2 - Semanas 2-5
Build
Desenvolvimento do agente com sua equipe
Implementar o Decision Layer
Conjuntos de regras como configuração versionada
Integração de sistemas (SAP, TOTVS etc.)
Testes com dados reais
Resultado: Agente produtivo em sua infraestrutura
Fase 3 - Semanas 5-6
Transfer
Entrega do código-fonte
Treinamento da equipe para operação autônoma
Documentação de código, prompts, conjuntos de regras
Configurar monitoramento e alertas
Documentar estratégia de saída
Resultado: Sua equipe opera o agente de forma autônoma
Para quais áreas
O Co-Build é adequado para qualquer processo baseado em conjuntos de regras que atualmente é gerenciado manualmente por pessoas. Áreas típicas:
Compliance e jurídico
Revisões regulatórias, revisão de contratos, extração de cláusulas, monitoramento de prazos.
Operações e cadeia de suprimentos
Processos de pedidos, gestão de fornecedores, inspeção de qualidade, processamento de reclamações.
Shared Services
Roteamento de tickets, classificação de solicitações, disponibilização interna de conhecimento, automação de service desk.
Específico por setor
Controle de exportações, despacho aduaneiro, sinistros de seguros, avaliação de crédito - qualquer processo baseado em regras.
O que você recebe
Código-fonte: Código completo do agente em seu repositório
Prompts: Todas as cadeias de prompts e system prompts, documentados e versionados
Conjuntos de regras: Regras de negócio como configuração versionada, não como hardcoding
Decision Layer: Audit trail, Human-in-the-Loop, restrições do sindicato e conformidade com PL 2338/2023
Documentação: Arquitetura, lógica de decisão, casos de teste, guia de implantação
Estratégia de saída: Treinamento, protocolo de transferência, período de suporte
Co-Build vs. SaaS vs. Inhouse
Co-Build
Plataforma SaaS
Inhouse
Time-to-Value
4-6 semanas
2-4 semanas
6-12 meses
Acesso ao código-fonte
Completo
Sem acesso
Completo
Vendor Lock-in
Nenhum
Alto
Nenhum
Governance / Auditoria
Decision Layer incluído
Dependente da plataforma
Precisa ser construído
Custos contínuos
Infraestrutura + manutenção opcional
Licença mensal
Custos de pessoal
Personalização
Ilimitada
Dentro da plataforma
Ilimitada
Cenário prático: Revisão de conformidade em um Shared Service Center
Um Shared Service Center revisa mensalmente 120 contratos de fornecedores quanto à conformidade - manualmente, com checklists no Excel.
Antes - manual
45 min por contrato (leitura, checklist, documentação)
Resultado: 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.
Aprofundamento no Agent Briefing
Nossa série de artigos para decisores que implementam AI Agents na empresa.
Integração via APIs - lógica do agent desacoplada do sistema destino
Definição: Document Agent
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.
O Document Agent lê um documento, compreende seu conteúdo e realiza uma avaliação profissional. Esta avaliação é verificada pelo Decision Layer, documentada e registrada no Audit Trail.
Como Funciona o Document Agent
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
Quais Documentos o Document Agent Processa
Finance: Notas fiscais, notas de crédito, recibos, comprovantes de pagamento, extratos bancários.
RH: Atestados médicos, contratos de trabalho, aditivos contratuais, certificados, cartas de referência.
Compliance: Documentos tributários, certificações, declarações, documentos de auditoria.
Decision Layer para Documentos
Cada processamento de documento gera um registro de decisão completo:
Entrada: Hash do documento, tipo de documento, campos extraídos
Conjunto de regras: Regra aplicada, versão, marca temporal
Avaliação: Confidence Score, indicador de risco
Resultado: Proposta de contabilização ou escalação
Routing: Decisão autônoma ou Human-in-the-Loop
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 arquitetura do Decision Layer.
Document Agent vs. OCR vs. processamento manual
Document Agent
Sistema OCR
Processamento manual
Compreensão
Contextual - compreende conteúdo e significado
Reconhecimento de caracteres + correspondência de templates
Capacidade cognitiva plena
Texto livre / manuscrito
Sim - compreensão linguística real
Limitado - falha em desvios
Sim
Velocidade
Segundos por documento
Segundos, mas frequentemente requer retrabalho
5-10 minutos por documento
Escalabilidade
Linear com o volume
Linear, mas manual em erros
Apenas com mais pessoal
Audit Trail
Automático por decisão
Limitado
Manual, frequentemente incompleto
Prática: Notas fiscais recebidas
Cenário: 500 notas fiscais recebidas por mês
Antes (manual)
8 minutos por nota fiscal (análise, contabilização, verificação)
~67 horas por mês
Taxa de erros na contabilização: 4-6%
Audit Trail: planilha Excel, mantida manualmente
Depois (Document Agent)
99,1% processados autonomamente (495 de 500 notas fiscais)
<1% escalados para funcionários (~5 notas fiscais/mês)
98% de todas as consultas com o remetente do documento resolvidas autonomamente
<0,5h de esforço manual por mês
Taxa de erros: abaixo de 0,3% (contabilização baseada em regras)
Resultado: 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.
Human-in-the-Loop
O agente decide: Contabilização, proposta de registro, condições de pagamento, consultas ao remetente do documento. O humano decide: Primeira aprovação de fornecedor, notas fiscais acima do limite de aprovação, desvios do valor do pedido >5%.
Áreas de Aplicação
Finance e Contabilidade
Processamento de notas fiscais, contabilização, verificação de documentos. Integração com TOTVS e SAP FI/CO. Solução pré-configurada: Finance AI Agents.
RH e People Operations
Atestados médicos, documentos contratuais, certificados. Integração com SAP SuccessFactors e Workday. Solução pré-configurada: HR AI Agents.
Compliance e Auditoria
Verificação automática de documentos recebidos contra políticas internas e regulações externas (LGPD (PT: RGPD)). O Decision Layer documenta cada decisão de verificação.
Integração
Document Agents se conectam a sistemas existentes por interfaces padronizadas:
SAP FI/CO, SAP S/4HANA
TOTVS
SAP SuccessFactors, Workday
SharePoint, Microsoft Teams
Caixas de e-mail (IMAP/Exchange)
Outros via REST/SOAP
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? Co-Build entrega agentes personalizados em 4-6 semanas.
--- 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.
Visão geral
Fontes verificadas
Cada resposta com referência da fonte, versão da regra e data de validade
5 anti-alucinação
Retrieval-First, verificação de fonte, Confidence, sem especulação, Audit Trail
4 canais
Teams Bot, SharePoint, interface web, API - onde seus colaboradores trabalham
RAG Pipeline
Indexação versionada de todas as fontes de conhecimento com atualização automática
Decision Layer
Confidence Scoring e routing - em caso de incerteza, encaminhamento em vez de resposta
Resposta imediata
Segundos em vez de horas - consistente em todas as unidades e fusos horários
Definição: Knowledge Agent
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.
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.
Princípio: Sem Fonte Não Há Resposta
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
Finance: Regras contábeis, políticas de viagem, processos de aprovação.
Compliance: Manuais de compliance, diretrizes de proteção de dados (LGPD (PT: RGPD)), processos de auditoria.
Segurança Arquitetônica contra Alucinação
Os Knowledge Agents são projetados para que o risco de alucinação seja minimizado arquitetonicamente:
Retrieval-First: O agent pesquisa primeiro os documentos relevantes antes de responder
Verificação de fonte: Cada afirmação deve ser rastreável a uma fonte concreta
Confidence Score: Com baixa confiança, nenhuma resposta é dada, mas sim um encaminhamento ao departamento responsável
Sem especulação: Quando a informação está ausente ou é contraditória, o agent encaminha ao departamento responsável
Audit Trail: Cada resposta é documentada com fonte, versão e confiança
Knowledge Agent vs. buscador empresarial vs. chatbot padrão
Knowledge Agent
Buscador empresarial
Chatbot padrão
Resultado
Resposta específica com fonte
Lista de documentos
Resposta gerada sem garantia de fonte
Referência da fonte
Sempre - com versão e validade
Link para o documento
Nenhuma ou não confiável
Alucinação
Prevenida arquitetonicamente (5 medidas)
Não aplicável
Frequente - sem controle
Em caso de incerteza
Encaminha ao departamento responsável
Exibe mais resultados
Responde mesmo assim
Audit Trail
Completo por resposta
Protocolo de busca
Histórico de chat
Prática: Consultas de RH
Cenário: 200 consultas de RH por mês (direitos de férias, regulações especiais, regulamentos internos)
Antes (manual)
15 minutos por consulta (RH pesquisa, verifica regulamento, responde)
~50 horas por mês
Respostas inconsistentes dependendo do analista
Tempo de espera para colaboradores: horas a dias
Depois (Knowledge Agent)
78% respondidas imediatamente (156 consultas) - segundos em vez de horas
22% escaladas ao RH (44 casos complexos) - com contexto
~11 horas por mês (apenas escalações)
100% consistência na interpretação de regras
Resultado: 39 horas por mês economizadas. Colaboradores recebem imediatamente uma resposta verificada. O RH se concentra nos casos complexos que exigem julgamento real.
Áreas de Aplicação
RH e People Operations
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".
Compliance e Regulação
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.
Onboarding
Novos funcionários obtêm acesso imediato ao conhecimento corporativo relevante, sem esperar por colegas disponíveis.
Integração
Os Knowledge Agents são acessíveis pelos seguintes canais:
Microsoft Teams Bot - diretamente no trabalho diário
Integração com SharePoint - integrado na intranet
Interface web - independente para consultas complexas
API - para integração em aplicações próprias
A base de conhecimento é mantida via SharePoint, Confluence ou upload direto de documentos.
--- 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.
Visão geral
5+ sistemas
SAP, TOTVS, Workday, SharePoint, AD - um agent coordena tudo
Pausável
Workflow pausa quando o humano precisa decidir - e retoma em seguida
Idempotente
Cada passo repetível sem efeitos colaterais - sem lançamentos duplicados
Decision Layer
Em cada ponto de decisão: autônomo ou Human-in-the-Loop
Baseado em API
Sem automação de GUI - integração estável via interfaces
Audit Trail
Cada passo com marca temporal, regra, versão e decisão de routing
Definição: Workflow Agent
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.
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.
Exemplo: Workflow de Atestado Médico
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
Cada passo é registrado. Cada decisão é rastreável. Diante de consultas ou informações faltantes, o workflow pausa - não interrompe.
Princípios de Orquestração
Entre sistemas: Um workflow pode coordenar SAP, TOTVS, SharePoint, e-mail e outros sistemas em um único fluxo
Baseado em decisões: O Workflow Agent toma decisões profissionais, não apenas regras se-então
Pausável: Quando faltam informações ou decisões humanas são necessárias, o workflow pausa, documenta e retoma após esclarecimento
Auditável: Cada passo cria uma entrada no Audit Trail, incluindo tempos de espera e escalações
Idempotente: Cada passo pode ser reexecutado sem efeitos colaterais
Workflow Agent vs. RPA vs. coordenação manual
Workflow Agent
Bot RPA
Coordenação manual
Controle
APIs + decisões profissionais
Cliques de GUI em interfaces
E-mail, telefone, tickets
Estabilidade
Contratos de API - independente de alterações na UI
Falha em alterações na UI
Dependente de pessoas
Capacidade de decisão
Decisões profissionais baseadas em conjuntos de regras
Apenas regras se-então
Capacidade de decisão plena
Interrupção
Pausa, aguarda, retoma
Interrompe - reinício necessário
Aguarda - frequentemente sem documentação
Audit Trail
Automático por passo
Baseado em screenshots
Manual, incompleto
Prática: Processo de onboarding
Cenário: 20 novos colaboradores por mês
Antes (manual)
3 dias úteis por onboarding
5 sistemas atualizados manualmente (SAP, AD, e-mail, controle de ponto, controle de acesso)
Taxa de erros: 12% (permissões ausentes, centro de custo incorreto)
Esforço do RH: 60 horas por mês
Depois (Workflow Agent)
4 horas por onboarding (incluindo aprovações manuais)
5 sistemas provisionados automaticamente via APIs
Taxa de erros: abaixo de 2% (atribuição baseada em regras)
Esforço do RH: 15 horas por mês
Resultado: 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.
Áreas de Aplicação
Processos de RH
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.
Processos de Finance
Recebimento de notas fiscais, verificação, contabilização, aprovação, lançamento. Orquestração via TOTVS, SAP FI/CO e interfaces bancárias.
Processos de Compliance
Verificação automática contra políticas, escalação em desvios, documentação no Audit Trail. Conformidade com a LGPD assegurada arquitetonicamente.
Decision Layer no Workflow
Cada passo do workflow que envolve uma decisão é roteado pelo Decision Layer:
Verificação profissional: Verificação do conjunto de regras em cada passo decisório
Routing: Continuação autônoma ou escalação para um humano
Documentação: Registro de decisão completo em cada passo
Versionamento: Cada regra aplicada com versão e marca temporal
Integração
Workflow Agents conectam sistemas existentes por interfaces padronizadas:
--- 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
3 tipos de agente
Document, Workflow, Knowledge - cada um com seu próprio Decision Layer
4-6 semanas
Do Discover ao PoC produtivo na sua infraestrutura
85-92% Zero-Touch
Casos rotineiros processados autonomamente - exceções escaladas a humanos
Sem SaaS, sem vendor lock-in - você possui código, prompts e regras
PL 2338/2023 ready
Audit Trail, Human-in-the-Loop, constraints de acordos coletivos e normas de CIPA
Construir um agente é fácil. Torná-lo enterprise-ready não.
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?
É 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.
Três tipos de agente
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.
Document Agent
Workflow Agent
Knowledge Agent
Função
O Especialista
O Coordenador
O Conhecedor
Tarefa
Ler, compreender e classificar documentos
Orquestrar processos entre sistemas
Responder perguntas a partir de regras internas
Substitui
OCR + template matching
RPA + workflows manuais
Motor de busca + chatbot
Exemplo
Extrair e classificar atestado médico
Coordenar onboarding via SAP, AD e e-mail
Responder sobre direito a férias com fonte verificada
Document Agents
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.
Human-in-the-Loop
O agente decide: Documentos padrão com alta confiança (notas fiscais com contabilização clara, atestados com prazos inequívocos). O humano decide: 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.
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.
Human-in-the-Loop
O agente decide: Roteamento, lançamentos contábeis, atualizações de status, notificações - tudo segundo regras definidas no Decision Layer. O humano decide: 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.
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.
Human-in-the-Loop
O agente decide: Consultas padrão com base de fontes clara (direito a férias, prazo de aviso prévio, competências). O humano decide: 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.
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.
Exemplo: atestado médico de ponta a ponta
Document Agent identifica o atestado médico na caixa de e-mail, extrai nome, período e código CID.
Workflow Agent verifica no sistema de RH: é o terceiro atestado em seis meses?
Knowledge Agent é acionado: "A partir de qual limite se aplica o programa de retorno ao trabalho conforme a convenção coletiva vigente?"
Workflow Agent avalia as respostas: limite não atingido - processo padrão.
Decision Layer verifica regras da CLT e constraints de acordos coletivos - calcular continuidade do pagamento.
Workflow Agent gera proposta de lançamento no sistema, informa o gestor de RH, documenta no Audit Trail.
Seis etapas, três tipos de agente, três sistemas - um Audit Trail contínuo.
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.
AI Agents afetam diferentes stakeholders. Cada um tem suas próprias perguntas.
CHRO / VP RH
Automatização de processos de RH em conformidade com sindicatos - Payroll, Leave, Recruiting - com Audit Trail completo e compliance trabalhista.
CFO / Finance Lead
Processamento automatizado de documentos, contabilização e conciliação - consistente em todas as filiais, auditável para auditores externos.
Sindicato / CIPA
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.
CTO / IT Lead
Arquitetura agnóstica. Integração via API com SAP, TOTVS, Workday. Sem vendor lock-in, acesso completo ao código-fonte.
Decision Layer
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.
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.
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.
SAP FI/CO, S/4HANA
SAP SuccessFactors
Workday
TOTVS
SharePoint, Teams
Active Directory
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.
Impacto de negócio
Casos rotineiros processados autonomamente - com documentação completa
Mesma interpretação de regras em todas as filiais
Cada decisão rastreável para auditores e sindicatos
Escalável sem aumento proporcional de pessoal
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.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam AI Agents na empresa.
--- 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: Dados Pessoais em Cada Documento
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.
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.
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.
Três Capabilities
Anonimização PII
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.
Redação de Contratos
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.
Detecção de Assinaturas
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.
Anonimização PII: Pseudonimização Roundtrip para LLM Input
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.
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.
Requisitos LGPD, acordo coletivo, regras do cliente
Detectar PII no documento
IA (NER + padrões)
Named Entity Recognition + padrões baseados em regras
Revisar falsos positivos
IA, se incerteza: Humano
Confidence Routing - "Silva" como sobrenome ou empresa?
Atribuir pseudônimos
Automático
Mapeamento consistente, "Pessoa_A" em vez de "João Silva"
Enviar documento pseudonimizado ao modelo
Automático
Sem decisão, encaminhamento puro
Re-anonimizar resultado
Automático
Aplicar tabela de mapeamento inversamente
Auditoria: o que foi anonimizado
Automático
Evidência LGPD no Audit Trail
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.
Redação de Contratos: Baseada em Regras, Dependente do Destinatário, Física
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.
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:
Elemento do contrato
Sindicato / CRE
Due Diligence
Consultor externo
Auditor independente
Partes contratantes (nomes)
✓ Visível
✗ Redatado
✗ Redatado
✓ Visível
Valores do contrato
✓ Visível
✓ Visível
✗ Redatado
✓ Visível
Salários / remuneração
✓ Visível
Agregado
✗ Redatado
✓ Visível
Cláusulas contratuais
✓ Visível
✓ Visível
Apenas tipos de cláusula
✓ Visível
Segredos comerciais
✗ Redatado
✓ Visível
✗ Redatado
✓ Visível
Assinaturas
✗ Redatado
✗ Redatado
✗ Redatado
✓ Visível
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.
Redação física: 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.
Detecção de Assinaturas: Encontrar, Verificar, Documentar
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.
Detecção de assinaturas
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.
Verificação massiva de arquivo: "Em quais dos 5.000 contratos falta uma contra-assinatura?" - resultados em minutos em vez de semanas.
Controle de qualidade de onboarding: "Todos os documentos obrigatórios do novo funcionário estão assinados?" - checklist automático, assinaturas faltantes escaladas como tarefas de workflow.
Preparação para auditoria: "Mostre todos os documentos sem assinatura do Q3 2025." - lista de exportação estruturada para o auditor independente.
┌─────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ 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
Importante: 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.
Decision Layer: Quem Decide o Quê
Cada capability tem seu próprio Decision Layer com pontos de decisão definidos.
Capability
Decisão
Decide
Por quê
PII
Quais categorias PII detectar?
Humano
Decisão organizacional, art. 5 LGPD
PII
"Müller" é nome ou empresa?
IA, a <80%: Humano
Ambiguidade NER - evitar falsos positivos
PII
Escolher método pseudonimização
Regras
Pseudônimos consistentes vs. aleatórios
Redação
Quais destinatários?
Humano
Decisão profissional, não automatizável
Redação
Quais campos são redatados?
Regras
Matriz dependente do destinatário
Redação
Tipo de cláusula desconhecido
Humano
Novos tipos precisam ser classificados
Assinatura
Assinatura presente?
IA
Computer Vision com valor de confiança
Assinatura
Assinatura confere com referência?
IA + Humano se anomalia
Alta correspondência: aceita. Anomalia: escalada
Assinatura
Sem referência disponível
Humano
Nova assinatura de referência deve ser registrada
Todos
Documentar Audit Trail
Automático
Cada decisão protocolada imutavelmente
Integração
Document Intelligence é uma capability do Document Agent existente - não software separado.
SAP DMS, SAP ArchiveLink - contratos e documentos de arquivos SAP
SharePoint, OneDrive - gestão documental via Microsoft Graph
Caixas de e-mail (IMAP/Exchange) - anexos processados automaticamente
File System Watcher - monitoramento de diretórios locais
REST API - para sistemas DMS customizados
Business Impact
Processamento LLM conforme LGPD: Documentos com dados pessoais podem ser processados pela primeira vez com modelos de linguagem - sem risco de privacidade.
Redação de contratos em minutos: Baseada em regras, dependente do destinatário, fisicamente segura.
Detecção proativa de lacunas em assinaturas: Assinaturas faltantes detectadas antes que o auditor pergunte.
Evidência de auditoria: Audit Trail documenta cada anonimização, cada redação, cada verificação de assinatura.
Sem ferramenta nova: Parte da arquitetura de agents existente. Sem vendor adicional, sem licença adicional.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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.
Regulamento eIDAS
O regulamento eIDAS (Regulamento (UE) No 910/2014) cria um marco legal europeu para identificação eletrônica e serviços de confiança.
Três Níveis de Assinatura
Assinatura Eletrônica Simples (AES)
Sem requisitos técnicos especiais. Exemplos: assinatura escaneada, nome sob email, clique em "Aceito". Adequada para confirmações internas sem requisito de forma legal.
Assinatura Eletrônica Avançada (AEA)
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.
Assinatura Eletrônica Qualificada (AEQ)
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.
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:
Três convenções coletivas em paralelo
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.)
Descansos regulatórios ANAC RBAC 117
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.)
Medical Grounding
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.
Crew-Pairing como restrição
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.
Bloqueios sazonais de férias
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.
Um pedido de férias na aviação. 10 etapas de decisão.
Um piloto solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:
Etapa
Decisão
Decisor
Fundamentação
1
Reconhecer grupo de pessoal e convenção
AI Agent
Agent reconhece: cockpit, cabine ou solo a partir do cadastro de pessoal
2
Classificar tipo de ausência
AI Agent
Agent reconhece: férias, descanso regulatório RBAC 117, Medical Grounding ou licença
3
Calcular direito a férias
Regra
30 dias base CLT + adicional por convenção (senioridade, longa distância)
4
Verificar conformidade ANAC RBAC 117
Regra
Descansos mínimos entre escalas, acumulação de horas de voo, limites de Duty Period
5
Verificar Crew-Pairing e lotação mínima
AI Agent
Agent verifica disponibilidade de tripulação contra plano de voo e lotação mínima por posição
6
Verificar bloqueio de férias
Regra
Alta temporada, fim de ano, períodos de bloqueio definidos em acordo coletivo
7
Gerar recomendação de aprovação
IA recomenda, humano decide
Todas as regras atendidas: recomendação de aprovação. Conflito: escalação com contexto
8
Monitorar limiar de afastamento INSS
Regra
15 dias empregador, a partir do 16o dia INSS. Medical Grounding rastreado separadamente
9
Calcular pagamento de férias + 1/3
Regra
Remuneração + 1/3 constitucional, adicionais por convenção
10
Gerar registro de auditoria
Regra
Dossiê completo: tipo de ausência, convenção, status RBAC 117, verificação Crew, resultado
Simulação
Calculado para volumes da aviação
Configuramos o Leave Decision Layer com parâmetros realistas de aviação. Três sindicatos, ANAC RBAC 117, Medical Grounding, Crew-Pairing.
Parâmetros da simulação
Colaboradores
5.000 a 80.000+ (cockpit, cabine, solo)
Convenções
ABRAPILOT/SNA (cockpit), SNAEAB (cabine), sindicato de solo
Regulatória
ANAC RBAC 117, certificados médicos Classe 1 e 2
Tipos de ausência
Férias, descanso regulatório, Medical Grounding, standby, licença
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.
Arquitetura e implementação
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.
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.
--- 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.
Convenções regionais Sindicato dos Químicos / ABIQUIM. (PT: Sindicatos setoriais / ACT.) Zero-Touch: modelo de simulação Gosign.
O que o Agent classifica
Cinco dimensões, um Agent
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:
Adicional de férias por modelo de turno
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.
Fracionamento de férias (CLT Art. 134)
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.
Afastamento com exposição a agentes químicos (NR-15)
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.
Lotação mínima em produção contínua
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.
Férias por tempo de serviço por convenção
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.
Um pedido de férias na química. 10 etapas de decisão.
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:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar tipo de ausência
AI Agent
Agent reconhece: férias, adicional de férias por turno, licença especial ou dia de folga compensatória
2
Reconhecer convenção regional e modelo de turno
AI Agent
Agent reconhece unidade, convenção regional e modelo de turno a partir do cadastro de pessoal e da escala
3
Calcular direito total
Regra
30 dias base + adicional por turno (2-5) + férias por tempo de serviço + dias adicionais por convenção
4
Calcular saldo restante
Regra
Direito total menos dias gozados e aprovados, incluindo saldo de período anterior
5
Verificar lotação mínima da escala
AI Agent
Agent verifica ocupação da escala contra regras de lotação mínima por qualificação
6
Reconhecer conflitos de equipe
AI Agent
Agent verifica: bloqueios entre colegas, pedidos paralelos, quota máxima de ausência simultânea
7
Gerar recomendação de aprovação
IA recomenda, humano decide
Todas as regras atendidas: recomendação de aprovação. Conflito: escalação com contexto ao gestor
8
Verificar limiar de afastamento
Regra
15+ dias de atestado: responsabilidade do empregador. A partir do 16o dia: encaminhamento INSS. Em exposição a agentes químicos: sinalização adicional
9
Calcular pagamento de férias + 1/3
Regra
Remuneração + 1/3 constitucional. Abono pecuniário se solicitado. Pagamento até 2 dias antes do início
10
Gerar registro de auditoria
Regra
Dossiê de decisão completo: tipo de ausência, direito, etapas de verificação, resultado, timestamp
Simulação
Calculado para volumes da indústria química
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.
Parâmetros da simulação
Colaboradores
5.000 a 50.000+ (produção, laboratório, administração)
Convenção coletiva
Sindicato dos Químicos / ABIQUIM, convenções regionais
Férias-base
30 dias (CLT Art. 129) + adicional por turno (2-5 dias) + férias por tempo de serviço
Modelos de turno
Turno contínuo, turno parcial, turno alternado, jornada normal
Fracionamento
Até 3 períodos (CLT Art. 134, Reforma Trabalhista 2017)
NR-15
Exposição a agentes químicos, acompanhamento de medicina ocupacional
Antes / Depois
Dimensão
Manual
Decision Layer
Tempo de processamento de pedido de férias
1-3 dias
< 30 segundos
Quota Zero-Touch
0%
83%
Prazos de encaminhamento INSS perdidos
12-18% (rastreamento manual)
0% (trigger automático)
Avisos de perda de férias (CLT Art. 137)
Frequentemente esquecidos
Automáticos, pontuais, individuais
Cálculo de adicional de férias por turno
Manual, propenso a erros
Baseado em regras, consistente
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
Convenções regionais Sindicato dos Químicos / ABIQUIM. CLT Art. 129-145. Resultados: modelo de simulação Gosign.
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.
Arquitetura e implementação
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.
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.
Convenção CONTRAF (bancários), SEEB (seguros). Itaú, Bradesco, Santander BR. (PT: Banco de Portugal, CMVM.) Zero-Touch: modelo de simulação Gosign.
O que o Agent classifica
Cinco dimensões, um Agent
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:
Férias obrigatórias em bloco (quatro olhos)
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.
Blocos obrigatórios Bacen/CVM
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.)
Feriados bancários e calendário de negociação
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.
Aposentadoria parcial progressiva
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.
Cinco regimes de remuneração em paralelo
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.
Um pedido de férias no setor financeiro. 10 etapas de decisão.
Um operador de mesa solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar tipo de ausência
AI Agent
Agent reconhece: férias, férias obrigatórias em bloco, aposentadoria parcial ou licença
2
Reconhecer regime de remuneração
AI Agent
Agent reconhece: CONTRAF, SEEB, executivo, diretor estatutário ou Risk Taker
3
Calcular direito a férias
Regra
30 dias base CLT ou direito individual (executivo/diretor) + correção aposentadoria parcial
4
Verificar férias obrigatórias em bloco
Regra
Posição sensível? Duração mínima atingida? Bloco já cumprido no ano corrente?
5
Verificar blocos Bacen/CVM
Regra
Posição de risco? Bloco consecutivo obrigatório já planejado?
6
Verificar feriados bancários e lotação
AI Agent
Agent verifica calendário bancário, lotação mínima da área, regra de substituição
7
Gerar recomendação de aprovação
IA recomenda, humano decide
Todas as regras e checks de compliance aprovados: recomendação. Conflito de compliance: escalação
8
Monitorar limiar de afastamento INSS
Regra
15 dias empregador, a partir do 16o dia INSS. Trigger automático ao RH
9
Calcular pagamento de férias + 1/3
Regra
Remuneração + 1/3 constitucional, adicionais por convenção
10
Gerar registro de auditoria
Regra
Dossiê completo: tipo, regime, status compliance, check Bacen, resultado
Simulação
Calculado para volumes do setor financeiro
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.
Quatro olhos, feriados bancários, lotação mínima mesa
Afastamento
Taxa do setor de serviços financeiros
Antes / Depois
Dimensão
Manual
Decision Layer
Tempo de processamento
1-3 dias
< 30 segundos
Quota Zero-Touch
0%
85%
Bloco obrigatório não cumprido
8-15% (monitoramento manual)
0% (monitoramento automático)
Férias obrigatórias em bloco
Verificação manual
Automático, pronto para fiscalização
Encaminhamentos INSS esquecidos
12-18%
0% (trigger automático)
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
Bacen, CVM. CONTRAF/SEEB. Itaú, Bradesco, Santander BR. (PT: Banco de Portugal, CMVM.) Resultados: modelo de simulação Gosign.
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.
Arquitetura e implementação
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.
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.
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.
O que o Agent classifica
Cinco dimensões, um Agent
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:
Escala de 6 dias e cálculo de férias
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.
Férias proporcionais para 64% de jornada parcial
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.)
Bloqueios sazonais de férias
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.
Férias de contratos intermitentes
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.
Convenções coletivas por estado
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.
Um pedido de férias no varejo. 10 etapas de decisão.
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:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar tipo de ausência
AI Agent
Agent reconhece: férias, licença especial, atestado médico ou folga compensatória
2
Reconhecer convenção estadual
AI Agent
Agent reconhece localização da loja e aplica a convenção do Sindicato dos Comerciários do estado
3
Calcular direito a férias
Regra
30 dias CLT, proporcional por tipo de contrato (parcial, intermitente, prazo determinado), fracionamento em até 3 períodos
4
Verificar bloqueio sazonal
Regra
Natal, Black Friday, inventário - períodos de bloqueio por loja
5
Verificar lotação mínima da loja
AI Agent
Agent verifica escala: lojas pequenas com 2-3 colaboradores, cada ausência conta
6
Reconhecer conflitos de equipe
AI Agent
Agent verifica pedidos paralelos, distribuição de férias escolares (critérios sociais)
7
Gerar recomendação de aprovação
IA recomenda, humano decide
Todas as regras atendidas: recomendação de aprovação. Bloqueio ou lotação mínima violada: escalação
8
Verificar limiar de afastamento
Regra
15+ dias de atestado: responsabilidade do empregador. A partir do 16o dia: encaminhamento INSS
9
Calcular pagamento de férias + 1/3
Regra
Remuneração + 1/3 constitucional. Abono pecuniário se solicitado. Pagamento até 2 dias antes do início
10
Gerar registro de auditoria
Regra
Dossiê de decisão completo: tipo de ausência, convenção, tipo de contrato, verificações, resultado
Simulação
Calculado para volumes do varejo
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.
Parâmetros da simulação
Colaboradores
5.000 a 100.000+ (lojas, centros de distribuição, administração)
Convenção coletiva
Comércio varejista, 26 estados + DF (Sindicato dos Comerciários / CONTRACS)
Limiar INSS (15 dias empregador / 16o dia encaminhamento)
Antes / Depois
Dimensão
Manual
Decision Layer
Tempo de processamento de pedido de férias
1-3 dias
< 30 segundos
Quota Zero-Touch
0%
87%
Erros de cálculo proporcional
5-12% (cálculo manual)
< 0,1% (baseado em regras)
Avisos de perda de férias (CLT Art. 137)
Frequentemente esquecidos em jornada parcial
Automáticos, pontuais, individuais
Prazos de encaminhamento INSS perdidos
12-18%
0% (trigger automático)
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
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.
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.
Arquitetura e implementação
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.
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.
Por que sistemas de ausências falham em organizações complexas
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)?
15+ tipos de ausência
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.
Cada atestado gera 4 processos
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.
Zero transparência de decisão
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.
O Decision Layer
Cada processo de ausência. Decomposto em etapas de decisão.
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.
CLT + Convenção Coletiva (CCT) + Acordo Coletivo (ACT) + contrato individual = direito total. Princípio da norma mais favorável
3
Calcular saldo restante
Regra
Direito menos gozado menos programado = disponível. Fracionamento em até 3 períodos (Reforma Trabalhista 2017: mínimo 14 + 5 + 5 dias)
4
Verificar conflitos de equipe e lotação mínima
AI Agent
Agent verifica calendário da equipe, férias coletivas, lotação mínima. Reconhece sobreposições e calcula capacidade disponível
5
Gerar recomendação de aprovação
AI Agent + Regra
Todas as regras atendidas: recomendação de aprovação ao gestor. Encaminhamento com contexto e recomendação
6
Escalar conflito de férias
Humano
Dois colaboradores, mesma semana, lotação mínima insuficiente. Critérios sociais (filhos em idade escolar, gestantes) exigem decisão humana
7
Calcular pagamento de férias + 1/3
Regra
Remuneração + 1/3 constitucional (CF Art. 7o, XVII). Abono pecuniário se solicitado. Pagamento até 2 dias antes do início
8
Monitorar limiar de afastamento INSS
Regra
Empregador paga 15 dias. A partir do 16o dia: encaminhamento ao INSS auxílio-doença. Trigger automático ao RH
9
Atualizar eSocial
Regra
Evento S-2230 (afastamento temporário) para o eSocial. Integração automática com sistema de folha e escala
10
Gerar registro de auditoria
Regra
Decisão, base legal, decisor, timestamp, hash de entrada - append-only, assinado SHA-256
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.
IA classifica. Regra calcula.
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.
Dados de saúde arquitetonicamente separados
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.
AI Agent, regra ou humano
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.
Aviso de perda de férias automatizado
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.
Governança
Não documentado posteriormente. Gerado no processo.
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.
Cada microdecisão gera um registro de auditoria
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.
ID da regra + versão
Base legal (CLT, CCT, ACT)
Dados de entrada (pedido, período, equipe)
Resultado (aprovação, recusa, escalação)
Decisor (regra / Agent / humano)
Hash de entrada (reproduzível)
Transparente para representação dos trabalhadores
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.
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.)
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.
Simulado para volumes Enterprise
Quatro setores. Calculados.
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.
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.
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.
Mais soluções de agentes
HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.
Quando começar? Priorização e prontidão de governança
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.
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.
O que o Agent classifica
SNA e SNEA, um Agent
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:
Cockpit (SNA): níveis de senioridade e escalas salariais
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.
Cabine (SNA): adicionais de turno e de voo
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.
Solo (SNEA): múltiplas faixas e funções
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.
ANAC RBAC 117: limites de tempo de voo como fronteira da folha
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.)
Diárias: 180+ tabelas por país conforme CLT
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 processamento de despesas de viagem no Travel Decision Layer.
Uma folha na aviação. 50 a 120 microdecisões.
Um Comandante em rota de longa distância. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar grupo de pessoal
AI Agent
Agent reconhece: cockpit, cabine, solo ou manutenção a partir do cadastro e código da função
2
Atribuir convenção coletiva
AI Agent
Agent atribui: SNA (aeronautas) ou SNEA (aeroviários). Adicionalmente: qual companhia aérea (subsidiárias têm convenções próprias)
3
Calcular remuneração base
Convenção coletiva
Lookup em tabela versionada: nível de senioridade, tipo de aeronave, nível de experiência
4
Calcular adicionais de turno
Convenção coletiva
Cabine: adicionais de turno e de voo. Solo: adicionais conforme escala. Cockpit: integrado na remuneração base
5
Verificar conformidade RBAC 117
Regra
Verificação ANAC RBAC 117: limites de horas de voo, FDP variável, limites acumulados. Na aproximação: escalação
6
Classificar diária
AI Agent
Agent classifica rota: quais países, qual duração de estadia, quais tabelas CLT se aplicam
7
Calcular diária
Regra
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
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
10
Gerar lançamentos contábeis
Regra
Contabilização FI/CO, multi-empresa (subsidiárias do grupo), centro de custo - determinístico
Simulação
Calculado para volumes de aviação
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.
Parâmetros da simulação
Tripulação
10.000 a 50.000+ (cockpit, cabine, solo, manutenção)
Convenções paralelas
2 a 5 (SNA aeronautas, SNEA aeroviários, eventualmente subsidiárias)
Múltiplos níveis (Copiloto a Comandante Sênior), contribuições previdenciárias
Antes / Depois
Dimensão
Manual
Decision Layer
Taxa de erro
3-12% (APA, acréscimo aviação)
< 0,3%
Quota Zero-Touch
0%
82%
Cálculo de diárias
Manual por rota, propenso a erros
Automático, 180+ países
Conformidade RBAC 117
Verificação separada, posterior
Integrada, limites em tempo real
Mudança de convenção (2 sindicatos)
Semanas por sindicato
< 24h (todos em paralelo)
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
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.
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.
Arquitetura e implementação
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.
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.
Convenções regionais Sindicato dos Químicos / ABIQUIM. Braskem, Oxiteno. (PT: Bondalti, CUF.) Zero-Touch: modelo de simulação Gosign.
O que o Agent classifica
Cinco dimensões, um Agent
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:
169 bases de remuneração
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.
Adicionais de turno com lógica de acumulação
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.
13o salário + FGTS 8% + PLR
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.
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.)
Pagamentos especiais por calendário
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.
Uma folha na química. 40 a 80 microdecisões.
Um trabalhador de turno na indústria química. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar convenção aplicável e faixa salarial
AI Agent
Agent reconhece localização da unidade, convenção regional e verifica enquadramento contra cadastro de pessoal
2
Calcular remuneração base
Convenção coletiva
Lookup em tabela versionada: convenção + faixa + nível
3
Classificar modelo de turno
AI Agent
Agent reconhece: turno parcial (6%), turno contínuo (10%) ou noturno fixo a partir da escala
4
Calcular e acumular adicionais
Convenção coletiva
Maior adicional prevalece, noturno sempre aditivo. Domingo 60%, feriado 150%
5
Calcular parcelas isentas
Regra
Adicionais noturnos, insalubridade (NR-15) e periculosidade (NR-16) conforme legislação aplicável
6
Classificar adicional NR-15/NR-16
AI Agent
Agent classifica posto de trabalho com base no PPRA/PGR: agentes químicos, calor, frio, ruído
7
Calcular 13o salário, FGTS e PLR
Regra
13o em duas parcelas + FGTS 8% mensal + PLR conforme convenção, tratamento fiscal diferenciado
8
Calcular contribuições previdenciárias
Regra
INSS com verificação de teto, FGTS 8%, contribuição sindical
9
Verificação de desvios contra mês anterior
IA detecta, humano decide
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
10
Gerar lançamentos contábeis
Regra
Contabilização FI/CO, centro de custo, período contábil - determinístico
Simulação
Calculado para volumes da indústria química
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.
Parâmetros da simulação
Colaboradores
5.000 a 50.000+ (produção, laboratório, administração)
Convenção coletiva
Sindicato dos Químicos / ABIQUIM, convenções regionais, faixas salariais
Bases de remuneração
169 (convenções x faixas) + progressão automática
Modelos de turno
Turno parcial, turno contínuo, noturno fixo
Pagamentos especiais
13o salário, férias + 1/3, FGTS 8%, PLR
Adicionais NR-15/NR-16
Insalubridade 10-40%, periculosidade 30%
Antes / Depois
Dimensão
Manual
Decision Layer
Taxa de erro
1-8% (APA)
< 0,1%
Quota Zero-Touch
0%
88%
Mudança de convenção
Semanas (múltiplas unidades manualmente)
< 24h (todas as unidades)
Cálculo de adicionais
Manual, propenso a erros
Baseado em regras, consistente
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
Gestão 13o, FGTS e PLR
Planilhas Excel por unidade
Centralizado, versionado
APA: American Payroll Association. Convenções regionais Sindicato dos Químicos / ABIQUIM. Braskem, Oxiteno. Resultados: modelo de simulação Gosign.
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.
Arquitetura e implementação
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.
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.
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.
O que o Agent classifica
Cinco regimes, um Agent
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:
5 regimes de remuneração paralelos
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.
Bonus-Deferral ao longo de 4-5 anos
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.
Malus/Clawback retroativo
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.
Obrigações prudenciais para traders
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.
Obrigações de reporte ao BCB e à CVM
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.)
Uma folha financeira. 30 a 60 microdecisões.
Um Risk Taker em um banco universal. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar regime de remuneração
AI Agent
Agent reconhece: convenção (faixas 1-9), fora de convenção, Risk Taker, Trading ou Sales/Advisory a partir dos dados contratuais
2
Verificar status de Risk Taker
AI Agent
Limite em BRL (equivalente a EUR 500.000), identificação contra catálogo funcional do BCB
3
Calcular salário fixo
Convenção/Contrato
Convenção: lookup de faixa em tabela salarial. Fora de convenção: acordo individual do contrato
4
Calcular remuneração variável
Regra
Avaliação de desempenho, teto de bônus 100% do fixo (200% com aprovação em assembleia)
5
Calcular split de deferral
Regra
40-60% ao longo de 4-5 anos, divisão em componentes de ações e dinheiro, datas de vesting
6
Realizar verificação de malus
IA detecta, humano decide
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
7
Verificar bloco de férias obrigatórias
Regra
10 dias úteis consecutivos por ano, cobertura, escalação em caso de descumprimento
8
Calcular contribuições previdenciárias
Regra
INSS com verificação de teto, previdência complementar, FGTS
9
Gerar dados de reporte regulatório
Regra
Relatório anual de remuneração: dados de Risk Takers, saldos de deferral, eventos de clawback para BCB e CVM
10
Gerar lançamentos contábeis
Regra
Contabilização FI/CO, multi-entidade, provisões de deferral - determinístico
Simulação
Calculado para volumes do setor financeiro
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.
Parâmetros da simulação
Colaboradores
2.000 a 30.000+ (Front Office, Middle Office, Back Office)
Regimes de remuneração
5 paralelos: convenção (faixas 1-9), fora de convenção, Risk Taker, Trading, Sales/Advisory
Limite de Risk Taker
Equivalente em BRL a EUR 500.000, identificação regulatória do BCB
Teto de bônus
100% do fixo (200% com aprovação em assembleia)
Deferral
40-60% ao longo de 4-5 anos, split ações/dinheiro
Malus/Clawback
5-7 anos de período de recuperação
Antes / Depois
Dimensão
Manual
Decision Layer
Taxa de erro
1-8% (APA)
< 0,1%
Quota Zero-Touch
0%
85%
Gestão de deferral
Excel, propenso a erros
Automatizado, versionado
Identificação de Risk Taker
Anual, manual
Contínua, automática
Reporte ao regulador
Semanas (preparação manual)
< 24h (gerado automaticamente)
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
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.
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.
Arquitetura e implementação
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.
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.
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.)
O que o Agent classifica
26 estados + DF, pisos regionais, um Agent
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:
576 bases de remuneração (26 estados + DF, pisos regionais)
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).
64% tempo parcial (contrato intermitente - Lei 13.467/2017)
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.)
100.000 sazonais (contrato por prazo determinado - CLT Art. 443)
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.
Acumulação de adicionais (só o maior, noturno aditivo)
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.
25,7% de rotatividade (fluxo permanente de admissões e desligamentos)
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.
Uma folha no varejo. 30 a 60 microdecisões.
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:
Etapa
Decisão
Decisor
Fundamentação
1
Classificar estado e convenção coletiva
AI Agent
Localização da loja identifica a convenção estadual do Sindicato dos Comerciários
2
Atribuir faixa salarial e nível
AI Agent
Função atribuída à faixa salarial, tempo de casa ao nível de experiência
3
Calcular remuneração base
Convenção coletiva
Lookup em tabela estadual: faixa + nível = salário base, verificação contra piso regional
4
Calcular proporcionalidade de jornada
Regra
Cálculo proporcional conforme horas contratuais, valor-hora para adicionais
5
Verificar tipo de contrato e enquadramento
AI Agent
CLT integral, parcial, intermitente (Lei 13.467) ou prazo determinado (Art. 443); encargos por tipo
6
Classificar e acumular adicionais
AI Agent + Convenção
Noturno 20% com hora reduzida, domingo 100%, feriado 100% - só o maior adicional, noturno aditivo
7
Calcular contribuições previdenciárias
Regra
INSS com faixa progressiva, FGTS 8%, contribuições patronais, intermitente proporcional
8
Verificar status de contrato sazonal
AI Agent
Controle de prazo (CLT Art. 443), limite de 2 anos, prorrogação, eSocial
9
Verificação de desvios
IA detecta, humano decide
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
10
Gerar lançamentos contábeis
Regra
Contabilização FI/CO, multi-loja, centro de custo - determinístico
Simulação
Calculado para volumes do varejo
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.
Parâmetros da simulação
Colaboradores
5.000 a 50.000+ (vendas, caixa, estoque, administração)
Convenção coletiva
Comércio varejista, 26 estados + DF, pisos regionais (Sindicato dos Comerciários / CONTRACS)
Bases de remuneração
576 (estados x faixas x níveis)
Taxa de tempo parcial
64% (CLT parcial, intermitente Lei 13.467, prazo determinado)
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.
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.
Arquitetura e implementação
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.
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.
--- 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.
American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 por incidente, convertido à taxa média)
O problema
Por que sistemas de folha falham em organizações complexas
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?
1-8% de taxa de erro
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.
EUR 260 (R$ 1.520) por erro
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.
Zero transparência de regras
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.
O Decision Layer
Cada folha. Decomposta em etapas de decisão.
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.
Etapa
Decisão
Decisor
Fundamentação
1
Validar categoria fiscal, deduções e dados previdenciários
Regra
Cruzamento com eSocial e dados cadastrais, determinístico
2
Verificar enquadramento na convenção coletiva
AI Agent
Agent classifica: qual convenção, qual faixa salarial, qual nível? Cruza com cadastro de pessoal e detecta inconsistências
3
Calcular remuneração base
Convenção coletiva
Lookup em tabela de convenção versionada: região + faixa + nível
4
Calcular adicionais (noturno/domingo/feriado)
AI Agent + Convenção
Agent classifica tipo de adicional a partir dos dados de turno. Convenção define percentuais + regra de acumulação
Contribuição do empregado + participação do empregador, verificação de limites fiscais
7
Calcular contribuições previdenciárias
Regra
INSS com verificação de teto, FGTS 8%, contribuições patronais
8
Aplicar consignações e descontos judiciais
Regra + Humano
Tabela de descontos determinística; em conflitos de prioridade: Human-in-the-Loop
9
Verificação de desvios contra mês anterior
IA detecta, humano decide
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.
10
Gerar lançamentos contábeis
Regra
Contabilização FI/CO, centro de custo, período contábil - determinístico
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.
IA classifica. Regra calcula.
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.
40 a 80 microdecisões por folha
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.
AI Agent, regra ou humano
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.
Humano no loop: não expertise, mas responsabilidade
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.
Governança
Não documentado posteriormente. Gerado no processo.
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).
Cada microdecisão gera um registro de auditoria
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.
ID da regra + versão
Convenção coletiva + período de vigência
Dados de entrada (horas, tipo de adicional)
Resultado (valor, tratamento fiscal)
Decisor (regra / convenção / humano)
Hash de entrada (reproduzível)
Transparente para a representação dos trabalhadores
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.
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.
Integração
Conecta-se ao seu ambiente de sistemas existente
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.
Fontes de dados
→Controle de ponto (SAP, TOTVS, Senior)
→Escalas de turno (sistemas de RH)
→Cadastro de pessoal (SAP HCM, Workday)
→eSocial (interface governamental)
→Base de convenções coletivas (versionada)
Payroll Decision Layer
Enquadramento em convenção coletiva
Cálculo de adicionais + acumulação
Parcelas isentas de tributação
Contribuições previdenciárias + verificação de teto
Consignações e descontos judiciais
Previdência complementar
Verificação de desvios + escalação
Sistemas de destino
→SAP HCM / SuccessFactors (folha)
→TOTVS Protheus / ADP (folha)
→SAP FI/CO (contabilização)
→eSocial (obrigações acessórias)
→Receita Federal (IRRF, DCTF)
Simulado para volumes Enterprise
Quatro setores. Calculados.
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.
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.
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.
Alavanca econômica
Eliminar correções antes que ocorram
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.
Mudança de convenção em horas, não semanas
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.
82-92% Zero-Touch. Humano só onde legalmente necessário.
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.
Auditoria fiscal é uma exportação, não um projeto
Dossiês de decisão selados por folha. Qual regra, qual entrada, qual resultado. Semanas de preparação viram minutos.
Segurança
Segurança Enterprise. Desde o dia um.
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.
100% infraestrutura do cliente
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.
LGPD by Design
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.
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).
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.
ISO 27001 / PS 951 cert-ready
Registry de controles integrado, Evidence Runs automatizados, políticas versionadas. Compliance em operação contínua, não documentada posteriormente.
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.
Mais soluções de agentes
HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.
Quando começar? Priorização e prontidão de governança
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.
--- 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.
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.
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.
A camada de modelos. Onde a compreensão linguística acontece.
Cloud-LLMs:
Azure OpenAI (ChatGPT, Claude) - regiões Brasil e UE, DPA da Microsoft
Amazon Bedrock (Claude, Llama, Mistral) - regiões Brasil e UE, DPA da AWS
Google Vertex AI (Gemini) - regiões UE, DPA do Google
Anthropic API (Claude) - com EU Data Processing
Self-Hosted-LLMs:
Llama (Meta) - Open Source, em hardware próprio
Mistral - Open Source, empresa da UE
DeepSeek - Open Source, custo-eficiente
gpt-oss (OpenAI) - Open Weight, Apache 2.0, completamente self-hostável. 120B em uma única H100, 20B em hardware de consumo de 16 GB.
Frameworks de inferência para Self-Hosted:
Ollama - Entrada simples, desenvolvimento local, deployment na borda
vLLM - Production-grade, otimizado para GPU, alto throughput
Híbrido:
Self-Hosted para dados sensíveis (RH, finanças)
Cloud-LLMs para cargas menos críticas (classificação de documentos)
Roteamento automático conforme classificação de dados
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: Modelos IA em comparação 2026 e LLM Self-Hosting para empresas.
Nossos AI Engineers possuem certificações Microsoft para Azure AI Services. As opções de deployment incluem Microsoft Azure, GCP e infraestrutura completamente self-hosted - a decisão arquitetônica pertence ao cliente, não ao fornecedor.
2. Pipeline RAG
Retrieval Augmented Generation - como agentes acessam o conhecimento empresarial.
Características de qualidade:
Chunking semântico (por conteúdo, não por número de página)
Enriquecimento de metadados (tipo de documento, versão, escopo de validade)
Busca híbrida (busca vetorial + busca por palavra-chave para precisão)
Citação de fonte em cada resposta (documento, página, parágrafo)
Re-indexação regular quando documentos são alterados
3. Orquestração
O controle de fluxo. Como agentes, sistemas e pessoas trabalham juntos.
Trigger.dev ou Camunda: Motor de workflow open-source. Workflows visuais, integração via API, webhooks. Self-hosted, sem vendor lock-in.
API Gateway: Ponto de entrada unificado. Rate limiting, autenticação, logging, monitoramento.
Sistema de Filas: Processamento assíncrono para processos em lote (fechamento mensal, importação em massa).
Sistema de Eventos: Reação em tempo real a documentos recebidos, mudanças de status, escalações.
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: Plataformas de orquestração de agentes.
4. Deployment
Onde a infraestrutura roda. Todas as opções com data residency no Brasil ou na UE.
Azure (Brasil e UE)
Azure Kubernetes Service (AKS) para orquestração de containers
Azure SQL / PostgreSQL para dados e Audit Trail
Azure OpenAI para LLM hosting
Regiões: Brazil South (São Paulo), West Europe, Germany West Central
AWS (Brasil e UE)
Amazon EKS para orquestração de containers
Amazon RDS / Aurora PostgreSQL para dados e Audit Trail
Amazon Bedrock para LLM hosting (Claude, Llama, Mistral)
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.
Após 12-18 meses, você opera a infraestrutura de forma independente.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
Como os componentes de infraestrutura se articulam arquitetonicamente - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure.
--- 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.
25 Anos de Software Empresarial
A Gosign desenvolve software para clientes empresariais desde 2001. Mais de 5.000 projetos para Airbus, Volkswagen, Shell e outros. O fundamento: segurança, escalabilidade e manutenibilidade em ambientes de grandes organizações.
Desde 2022, o foco está em infraestrutura de IA e agent engineering. Não como pivot, mas como evolução consequente. Os requisitos são os mesmos: arquitetura, governança, escalabilidade.
Não somos uma startup de IA de dois anos. Somos uma empresa de engenharia com 25 anos construindo software empresarial.
O Que Construímos Hoje
Integrações Personalizadas
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.
Desenvolvimento de APIs
REST e GraphQL. Autenticação, rate limiting, versionamento, documentação.
Arquitetura de Sistemas
Modelo de dados, estratégia de implantação, conceito de escalamento, arquitetura de segurança.
Plataformas Empresariais
Dashboards, portais de auditor, interfaces de chat, ferramentas de workflow.
Princípios de Engenharia
TDD & Pair Programming contínuo: Cada linha de código é escrita em pair programming. Tests antes do código. Cada função tem tests. Cada merge requer tests verdes.
CI/CD: Pipeline automatizado. Cada push é testado. Cada merge é implantado.
Code Review: Quatro olhos para todas as mudanças em produção.
Security by Design: RBAC, criptografia, validação de entrada desde o dia 1.
Audit Trail: Cada mudança documentada. Quem mudou o quê quando.
Os princípios de engenharia que valem para desenvolvimento de software empresarial também valem para infraestrutura de IA. 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.
A diferença: um AI Agent toma decisões profissionais que devem ser documentadas e rastreáveis. Isso requer componentes arquiteturais adicionais - o Decision Layer, Governance by Design, controles Cert-Ready. Mas o fundamento é engenharia de software.
25 anos desse fundamento é a razão pela qual nossa infraestrutura de IA funciona.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- 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.
Casos e Zero-Touch: modelo de simulação Gosign. Taxa de IROP: EUROCONTROL / US DOT BTS / ANAC Brasil, 2024.
O que o Agent classifica
Três grupos de pessoal, um Agent
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.
Centenas de rotações por dia
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.
Três a cinco países por dia de serviço
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.
Override tarifário por grupo de pessoal
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.
Volatilidade IROP em tempo real
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.
Governance de volume sem amostragem
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.
Uma rotação. 40 a 120 micro-decisões.
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:
Passo
Decisão
Decisor
Justificativa
1
Ler rotação da escala de serviço
Automático
Importação de dados, sem decisão
2
Determinar sequência de países
Motor de regras
GPS ou plano: quais países, qual duração
3
Selecionar diária por país
Motor de regras
Diárias conforme CLT e convenções coletivas
4
Verificar override de convenção coletiva
Motor de regras
Convenção coletiva específica de tripulação prevalece sobre taxas legais
Atraso, desvio, reposicionamento: AI classifica o tipo
7
Recalcular impacto do IROP
Motor de regras
Duração ou país alterado: recalcular diária
8
Verificar hotel de layover
AI + Motor de regras
AI extrai dados do hotel, motor de regras verifica conformidade com política
9
Atribuir centro de custo
Motor de regras
Rotação para frota, frota para centro de custo
10
Gerar dossiê de auditoria
Automático
Dossiê de decisão selado por rotação
Simulação
Calculado para volumes de aviação
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.
Parâmetros da simulação
Membros da tripulação
10.000 a 50.000+ (múltiplos grupos de pessoal com convenções coletivas próprias)
Convenções coletivas
2 a 5 em paralelo (por grupo de pessoal e companhia aérea)
Casos/ano
100.000 a 1.000.000+
Jurisdições
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.
Integração de sistemas
Planejamento de tripulação → Decision Layer → ERP/Folha de Pagamento
Taxa de IROP
10 - 20% de todas as rotações com desvio do plano (padrão do setor)
Antes / Depois
Dimensão
Manual
Decision Layer
Custo de processamento
a partir de EUR 53 / R$ 310 (base GBTA)*
< EUR 9 (R$ 53)
Taxa de erro
19% (GBTA)
< 0,3%
Tempo de processamento
5 - 12 dias úteis
Minutos
Taxa Zero-Touch
0%
95%
Prontidão para auditoria
Reconstruída manualmente
Gerada automaticamente
Mudança de convenção coletiva
Semanas
< 24h
Correção retroativa
Sobrescrita manual
Estorno + ajuste (append-only)
* 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.
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.
Arquitetura e implementação
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.
--- 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.
Casos e Zero-Touch: modelo de simulação Gosign. Benchmarks do setor: GBTA Foundation, 2015.
O que o Agent classifica
Três splits, um Agent
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.
Divisão tripla por transação
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.
Semanas multi-cliente divididas automaticamente
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.
Conflito de políticas resolvido automaticamente
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ê.
Custos de representação por jurisdição
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%.
Faturamento de clientes documentado automaticamente
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.
Uma semana de consultoria. 20 a 60 micro-decisões.
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:
Passo
Decisão
Decisor
Justificativa
1
Atribuir viagem ao projeto do cliente
Motor de regras
Integração com calendário ou CRM
2
Determinar diária
Motor de regras
Diárias conforme CLT e convenções coletivas
3
Dividir hospedagem: repassável vs. interno
Motor de regras
Condições contratuais do cliente determinam o split
4
Verificar política de viagem do cliente
Motor de regras
Econômica do cliente vs. primeira classe interna
5
Aplicar política mais restritiva
Motor de regras
A mais restritiva prevalece
6
Classificação tributária
Motor de regras
Dedutível, parcialmente dedutível, representação
7
Dividir dia com múltiplos clientes
AI + Motor de regras
AI determina alocação de tempo, regras aplicam split de custos
8
Gerar base de faturamento por cliente
Automático
Documentação de despesas pronta para auditoria por cliente
9
Classificar despesas de representação
AI + Motor de regras
AI identifica tipo de comprovante, motor de regras aplica alíquotas de dedução por jurisdição
10
Gerar dossiê de auditoria
Automático
Dossiê de decisões lacrado por semana de consultoria
Simulação
Calculado para volumes de consultoria
Configuramos o Travel Decision Layer com parâmetros realistas de consultoria e calculamos. Os resultados mostram o que muda em volumes Enterprise.
Parâmetros da simulação
Consultores
100 a 500+ (com regras de política específicas por cliente)
Contratos de clientes
10 a 50+ em paralelo (cada um com suas políticas de viagem)
Casos/ano
50.000 a 250.000+
Jurisdições
Multi-jurisdição (BR, PT, DE, AT, CH, outros países UE). LGPD (PT: RGPD) para proteção de dados.
Integração de sistemas
CRM/controle de horas → Decision Layer → ERP/Folha de pagamento
Proporção de representação
15 - 25% de todos os casos contêm comprovantes de representação
Antes / Depois
Dimensão
Manual
Decision Layer
Custo de processamento
a partir de EUR 53 / R$ 310 (base GBTA)*
< EUR 9 (R$ 53)
Taxa de erro
19% (GBTA)
< 0,3%
Tempo de processamento
5 - 12 dias úteis
Minutos
Taxa Zero-Touch
0%
85%
Prontidão para auditoria
Reconstruída manualmente
Gerada automaticamente
Precisão do split
Estimada manualmente
Calculada deterministicamente
Faturamento ao cliente
Atribuído manualmente
Documentado automaticamente
* 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.
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.
Arquitetura e implementação
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.
--- 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.
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).
O que o Agent classifica
27 estados, 30+ jurisdições UE, um Agent
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.
Atribuição de país baseada em GPS
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.
Regulamentação de transporte documentada automaticamente
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.)
Consistência em toda a frota
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.
Modo zero-touch para motoristas
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.
Precisão ao minuto em cruzamentos de fronteira
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.
Uma viagem de motorista. 15 a 40 micro-decisões.
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:
Passo
Decisão
Decisor
Justificativa
1
Ler rastreamento GPS da telemática
Automático
Importação de dados, sem decisão
2
Determinar sequência de estados/países e duração
Motor de regras
Coordenadas GPS mapeadas em jurisdições
3
Selecionar diária por localização
Motor de regras
Diárias conforme CLT e convenções coletivas
4
Calcular cruzamento de fronteira à meia-noite
Motor de regras
Cálculo proporcional para cruzamento de fronteira à meia-noite
5
Verificar limite de deslocamento de longa duração
Motor de regras
Limites baseados em duração por jurisdição
6
Gerar dados de documentação regulatória
Automático
Documentação de deslocamento como base de dados
7
Atribuir centro de custo da frota
Motor de regras
Veículo para frota, frota para centro de custo
8
Gerar exportação para folha de pagamento
Automático
Dados de diárias prontos para lançamento
9
Verificar conformidade do tempo de descanso
Motor de regras
Tempos de condução e descanso conforme legislação vigente (BR: CLT + ANTT; PT: Regulamento UE 561/2006)
10
Gerar dossiê de auditoria
Automático
Dossiê de decisões lacrado por viagem de motorista
Simulação
Calculado para volumes logísticos
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.
Parâmetros da simulação
Frota
200 a 2.000+ veículos (próprios e subcontratados)
Motoristas
300 a 3.000+ (com diferentes modelos contratuais)
Operações/ano
500.000 a 2.000.000+
Jurisdições
27 estados BR + 30+ jurisdições EU/EFTA. LGPD (PT: RGPD) para proteção de dados.
Integração sistêmica
Telemática → Decision Layer → ERP/Folha
Travessias de fronteira/dia
500 a 5.000+ (dependente da frota)
Antes / Depois
Dimensão
Manual
Decision Layer
Custo de processamento
a partir de EUR 53 / R$ 310 (base GBTA)*
< EUR 5 (R$ 29)
Taxa de erro
19% (GBTA)
< 0,1%
Tempo de processamento
5 - 12 dias úteis
Minutos
Taxa Zero-Touch
0%
95%
Prontidão para auditoria
Reconstruído manualmente
Gerado automaticamente
Dados regulatórios de transporte
Inseridos manualmente
Gerados automaticamente
Consultas de motoristas
3 - 5 por semana
< 0,1 por semana
* 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.
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.
Arquitetura e implementação
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.
--- 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.
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.
O que o Agent classifica
10.000 transações/mês, um Agent
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.
100% verificação de política em vez de 5% amostragem
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.
Vinculação CRM automática
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.
Liquidação semanal em vez de transações individuais
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.
Custos de representação por jurisdição
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%.
Fechamento trimestral em minutos
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.
Uma semana de vendas. De 30 a 80 micro-decisões.
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:
Passo
Decisão
Decisor
Justificativa
1
Vincular viagem com oportunidade do CRM
Motor de regras
Cruzamento de dados de calendário e CRM
2
Determinar diária
Motor de regras
Baseado em localização e duração
3
Calcular reembolso de quilometragem
Motor de regras
Distância, tipo de veículo, taxa
4
Verificar política de representação
Motor de regras
Valor, participantes, finalidade
5
Verificar política de hotel
Motor de regras
Limite de preço por categoria de cidade
6
Agrupar em liquidação semanal
Automático
Todas as viagens de uma semana agregadas
7
Atribuir centro de custo e oportunidade
Motor de regras
Cliente, projeto, atribuição de receita
8
Gerar exportação para folha de pagamento
Automático
Liquidação semanal como lançamento
9
Classificar despesas de representação
AI + Motor de regras
AI reconhece tipo de recibo e participantes, motor de regras aplica cotas de dedução
10
Gerar dossiê de auditoria
Automático
Dossiê de decisões selado por semana de vendas
Simulação
Calculado para volumes de vendas
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.
Parâmetros da simulação
Representantes de campo
200 a 2.000+ (por região e hierarquia)
Casos/mês
10.000 a 50.000+
Jurisdições
Multi-jurisdição (BR, PT, UE, LATAM). LGPD (PT: RGPD) para proteção de dados.
Integração de sistemas
CRM → Decision Layer → ERP/Folha de pagamento
Participação de representação
20 - 30% de todos os casos contêm recibos de representação
Políticas
3 - 10 paralelas (por região, hierarquia, classe de cliente)
Antes / Depois
Dimensão
Manual
Decision Layer
Custo de processamento
a partir de EUR 53 / R$ 310 (base GBTA)*
< EUR 7 (R$ 41)
Taxa de erro
19% (GBTA)
< 0,5%
Tempo de processamento
5 - 12 dias úteis
Minutos
Taxa Zero-Touch
0%
90%
Prontidão para auditoria
Reconstruída manualmente
Gerada automaticamente
Verificação de políticas
5 - 10% (amostragem)
100%
Liquidação semanal
Compilada manualmente
Agregada automaticamente
* 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.
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.
Arquitetura e implementação
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.
--- 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.
GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados.
O Problema
Por que ferramentas de despesas falham em organizações complexas
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.
EUR 53 (R$ 310) por caso
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.
19% taxa de erro
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).
Zero preparação para auditoria
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.)
O Decision Layer
Cada caso. Decomposto em passos de decisão.
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.
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.
Mesmo input, mesmo resultado
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.
40 a 120 decisões individuais por caso
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.
Motor de regras, convenção coletiva ou pessoa
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.
O colaborador não confirma. Pode contestar.
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.
Governance
Não documentado retroativamente. Gerado no processo.
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.)
Cada microdecisão gera um registro de auditoria
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.
ID da regra + versão da regra
Dados de entrada (o que estava disponível?)
Resultado (o que foi decidido?)
Carimbo de data/hora
Ator (motor de regras / convenção / pessoa)
Hash do input (reproduzível)
Transparente para sindicatos (PT: Comissão de Trabalhadores)
Regras acessíveis. Decisões rastreáveis. Pontuação de anomalias controlável por Feature Flag. Relatórios pseudonimizados. Compliance e performance arquitetonicamente separados.
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.)
Sem relatório trimestral, sem auditoria por amostragem. Cada caso individual é verificado contra o motor de regras. Desvios são detectados e documentados imediatamente.
Dimensão
Ferramenta de despesas tradicional
Travel Decision Layer
Modelo de decisão
Pessoa preenche, gestor aprova
Decision Layer aplica regras, pessoa tem veto
Complexidade normativa
Políticas básicas, sem lógica de convenção coletiva
Tabelas de decisão versionadas: legislação tributária, diárias, convenções coletivas
Audit Trail
Recibo armazenado, decisão não documentada
Cada microdecisão documentada: regra, input, resultado, carimbo de data/hora
Fiscalização
Reconstrução manual a partir de arquivos
Exportação: dossiê de auditoria selado por caso, reproduzível via hash do input
Experiência do colaborador
Formulário, upload, aguardar aprovação
Processamento automático, notificação, opção de veto
Escalabilidade
Linear: mais casos = mais revisores
Constante: 100 ou 100.000 casos, mesmo motor de regras
Representação dos trabalhadores
Intransparente, difícil de auditar
Motor de regras transparente, pontuação de anomalias por Feature Flag, relatórios pseudonimizados
Simulado para volumes enterprise
Quatro setores. Calculados.
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.
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.
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.
Alavanca econômica
Verificação sistemática de regras em vez de amostragem
Cada caso passa pelo mesmo motor de regras. Desvios são detectados e documentados, não descobertos na reconciliação trimestral.
Sem workflows de aprovação para casos padrão
Tempo de processamento de dias para minutos. Gestores aprovam apenas exceções.
Atribuição automática de centros de custo e projetos
Sem mapeamento manual para milhares de casos. Sem gargalo no fechamento mensal.
Dossiês de decisão prontos para fiscalização gerados no processo
Fiscalização é uma exportação, não um projeto de pesquisa. Semanas viram minutos.
Segurança
Segurança Enterprise. Desde o dia um.
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.
100% infraestrutura do cliente
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.)
LGPD by Design
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.)
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.
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.
ISO 27001 / SOC 2 cert-ready
Registro de controles integrado, execuções de evidência automatizadas, políticas versionadas. Compliance em operação contínua, não documentado retrospectivamente.
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.
Aprofundamento no Agent Briefing
Nossa série de artigos para executivos que implementam agentes de IA na empresa.
--- Serviços ---
> AI Agents, Finance Agents, HR Agents, Infraestrutura de IA, Document Intelligence e assinaturas digitais eIDAS.
O Que Construímos
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.
AI Agents
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.
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.
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.
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.
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.
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.
--- 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 o site foi hackeado?
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.
Os 10 motivos mais comuns para sites serem hackeados
1. Versão desatualizada do CMS
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.
2. Plugins/extensions inseguros
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).
3. Senhas fracas
"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.
4. Falta de SSL/HTTPS
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.
5. Hospedagem insegura
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.
6. Sem Web Application Firewall (WAF)
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.
7. Falta de backups
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.
8. Upload de arquivos inseguro
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.
9. SQL Injection
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.
10. Sem monitoramento
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.
Site hackeado? A Gosign pode ajudar. Consultoria emergencial disponível.
25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA
Checklist: medidas imediatas após um ataque
1Colocar o site offline (modo de manutenção)
2Alterar senhas (CMS, FTP, banco de dados, hospedagem)
3Salvar backup (estado atual para forense)
4Identificar o último backup limpo
5Executar varredura de malware
6Identificar o ponto de entrada (verificar logs)
7Limpar e fechar a vulnerabilidade
8Colocar o site novamente online
9Google Search Console: solicitar revisão
10Configurar monitoramento para que não aconteça novamente
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.
--- 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.
## 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
## 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.
Membro da Associação Federal Alemã de Economia Digital (BVDW)
## 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.
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/)
--- 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.
Termos e Condições Gerais
Aviso: Este documento é uma tradução informativa. A versão alemã é juridicamente vinculante. Em caso de divergências, prevalece a versão alemã.
→ Deutsche Fassung (versão alemã)
Gosign GmbH - Infraestrutura de IA, desenvolvimento de agentes e desenvolvimento de software
Versão 3.1 - Data: março de 2026
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:
Infraestrutura empresarial de IA e desenvolvimento de agentes: 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.
Decision Layer e arquitetura de Governance: 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).
Desenvolvimento de software: 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.
Hosting e serviços operacionais (opcional): 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.
Enablement e transferência de conhecimento: 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.
Delimitação: 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.
Base de clientes: 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.
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.
§ 2 Definições
Os seguintes termos são utilizados nestes TCG com o significado indicado abaixo:
"Agent" 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).
"Audit Trail" designa o registro completo e cronológico de todos os Decision Records e eventos no sistema.
"Auditor Portal" 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.
"Cert-Ready" 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.
"Component Manifest" 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.
"Control" 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").
"Decision Layer" 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.
"Decision Record" 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.
"Evidence" designa uma prova gerada automaticamente de que um Control foi cumprido em um momento específico.
"Human-in-the-Loop" 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.
"Maintenance" 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.
"Perpetual License" 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.
"Componentes de Plataforma" (Plattform-Komponenten) 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.
"Transferência de código-fonte" (Quellcode-Transfer) 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.
"Software Bill of Materials (SBOM)" designa a relação de todos os componentes de código aberto utilizados na solução e suas respectivas licenças, conforme § 7.4.
"System of Record" 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.
"Terceiros Autorizados" (Zulässige Dritte) 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.
§ 3 Celebração do contrato
Proposta e pedido: 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.
O contrato é celebrado somente quando a Gosign confirma o pedido em forma textual ou inicia a execução.
Contrato-quadro e fases do projeto: 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.
Tipos de contrato por fase: 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.
Os contratos podem ser celebrados por escrito, eletronicamente ou em forma textual. A Gosign conserva o texto do contrato e estes TCG.
§ 4 Serviços da Gosign
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.
Local de prestação: 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.
Coordenação do projeto: Ambas as partes designam pessoas de contato. A Gosign informa regularmente sobre o progresso do projeto.
Prazos: Prazos são vinculantes apenas quando expressamente acordados como tal. Atrasos não atribuíveis à Gosign estendem os prazos proporcionalmente.
Solicitações de alteração (Change Requests): Alterações no escopo dos serviços requerem acordo por escrito sobre custos adicionais e prazos.
Proof of Concept (PoC): 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.
Entregas parciais: A Gosign está autorizada a realizar entregas parciais razoáveis.
4.1 Aceitação de entregas de obra
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.
§ 5 Obrigações de cooperação do cliente
O cliente fornece tempestivamente todos os documentos, informações, dados e acessos necessários.
O cliente designa uma pessoa de contato qualificada com poderes de decisão.
Infraestrutura técnica: Quando os serviços forem prestados nos sistemas do cliente, este fornece a infraestrutura. A Gosign informa sobre os requisitos do sistema.
Testes e aceitações: O cliente coopera ativamente, documenta erros e não atrasa aprovações de forma injustificada.
Manutenção e backup: 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.
Legalidade: O cliente é responsável pela legalidade de todos os conteúdos e dados fornecidos e indeniza a Gosign contra reclamações de terceiros.
Atrasos e custos adicionais decorrentes do descumprimento das obrigações de cooperação são de responsabilidade do cliente.
§ 6 Disposições especiais para infraestrutura de IA e desenvolvimento de agentes
6.1 Escopo dos serviços
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.
A proposta indica quais Componentes de Plataforma (§ 7.2) são utilizados e contém um Component Manifest como anexo.
6.2 Arquitetura de três camadas e responsabilidades
As soluções de IA desenvolvidas pela Gosign distinguem três camadas de processamento com diferentes responsabilidades:
(a) Análise (modelo de IA): 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.
(b) Decisão (Decision Layer): 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.
(c) Execução (integração/ferramenta): 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.
6.3 Human-in-the-Loop
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.
6.4 Abordagem model-agnostic
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.
6.5 Bias Monitoring
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.
6.6 Uso de dados para IA
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.
6.7 FinOps e custos dependentes de consumo
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.
6.8 Requisitos regulatórios
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.
6.9 Indenização
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.
§ 7 Direitos de uso, propriedade intelectual e acesso ao código-fonte
7.1 Direitos de uso sobre resultados de trabalho específicos do cliente
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:
(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)
(b) Prompts e templates de prompts desenvolvidos para o cliente e identificados como específicos do cliente no Component Manifest
(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)
(d) Documentação técnica da solução específica do cliente
(e) Dados e configurações do cliente em todos os formatos
A classificação em § 7.1 ou § 7.2 decorre do Component Manifest conforme § 7.2, parágrafo 4.
O direito de uso inclui o direito de modificação e desenvolvimento para a operação comercial própria do cliente.
A transferência a terceiros ou sublicenciamento requer o consentimento prévio por escrito da Gosign. Não é necessário consentimento para a transferência a Terceiros Autorizados. Terceiros Autorizados são:
(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)
(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
(iii) Auditores, auditoria interna e autoridades reguladoras no âmbito de obrigações legais ou contratuais de auditoria
(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
O cliente garante que os Terceiros Autorizados observam obrigações de proteção e confidencialidade pelo menos equivalentes.
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.
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.
7.2 Componentes de Plataforma da Gosign
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.
O cliente recebe um direito de uso permanente sobre a versão entregue 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.
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.
Os Componentes de Plataforma são identificados na proposta em um Component Manifest. O Component Manifest lista pelo menos todos os Componentes de Plataforma relevantes 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. Alterações no Component Manifest requerem forma textual e são acordadas como aditivo à proposta ou em um Change Request. 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.
O código-fonte dos Componentes de Plataforma é informação confidencial e segredo comercial da Gosign 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.
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.
7.3 Source Code Escrow
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.
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:
(a) Pedido de insolvência da Gosign (abertura ou indeferimento por insuficiência de massa)
(b) Cessação do suporte ao produto: 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.
(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.
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.
7.4 Componentes de código aberto
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.
A Gosign não utiliza componentes sob licenças copyleft (em particular GPL, AGPL), salvo se expressamente indicados na proposta e aprovados pelo cliente.
7.5 Componentes reutilizáveis e isolamento de mandantes
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.
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.
7.6 Direito de uso limitado (alternativa para projetos de software puros)
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.
7.7 Taxas de licença e manutenção
Para resultados de trabalho específicos do cliente (§ 7.1), não há taxas de licença periódicas.
Para Componentes de Plataforma da Gosign (§ 7.2), aplica-se o seguinte: O direito de uso sobre a versão entregue (Perpetual License) está incluído na remuneração acordada na proposta. Taxas periódicas adicionais somente se aplicam quando expressamente indicadas na proposta.
Para manutenção contínua, atualizações de segurança e evolução 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.
Se o cliente rescindir o contrato de manutenção, o direito de uso sobre a última versão entregue permanece integralmente em vigor. 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.
Sem acordo expresso na proposta, não há taxas periódicas.
7.8 Modificações do cliente em Componentes de Plataforma
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.
Se o cliente realizar alterações nos Componentes de Plataforma fora dos Extension Points documentados, 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.
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. 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.
As obrigações de segurança do cliente conforme § 9 não são afetadas pelas modificações.
7.9 Contribuições do cliente para Componentes de Plataforma
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").
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.
Esta cláusula não obriga o cliente a submeter Contribuições.
7.10 Momento da entrega
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.
§ 8 Hosting e serviços operacionais
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:
Managed Services na infraestrutura do cliente: 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.
Centro de dados: 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.
Disponibilidade: Sem SLA, não há garantia de disponibilidade mínima. A Gosign almeja alta disponibilidade.
Janelas de manutenção: Manutenção planejada fora do horário comercial com aviso prévio.
Backup: Backup diário com retenção rotativa de 7 dias, salvo acordo em contrário.
Transição e saída: 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.
§ 9 Segurança, manutenção e atualizações
Atualizações de segurança obrigatórias: 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.
Dever de tolerância: O cliente não pode recusar atualizações de segurança. A segurança e integridade do sistema têm prioridade.
Recusa: 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.
Atualizações opcionais: Atualizações não relacionadas à segurança somente mediante acordo.
Testes de penetração: 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.
Resposta a incidentes: 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.
§ 10 Remuneração e condições de pagamento
Os preços constam da proposta, acrescidos do IVA aplicável.
Faturamento por tempo e materiais ou preço fixo conforme acordado.
Despesas acessórias e de viagem somente mediante aprovação prévia.
Prazo de pagamento: 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).
Pagamentos parciais em projetos de maior duração conforme o plano de marcos.
Compensação somente com créditos incontroversos ou judicialmente estabelecidos.
§ 11 Responsabilidade
Ilimitada: Por dolo, culpa grave, lesão à vida/corpo/saúde, garantia, responsabilidade pelo produto.
Obrigações cardinais: Por culpa leve, limitada ao dano tipicamente previsível.
Limite máximo de responsabilidade: 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.
Danos indiretos, consequenciais e lucros cessantes: Excluídos, salvo dolo, culpa grave ou violação de obrigações cardinais.
Perda de dados: Responsabilidade apenas pelo custo de restauração a partir dos backups adequados do cliente.
Resultados de IA: Sem responsabilidade por decisões baseadas em resultados de IA, desde que a Gosign não tenha violado obrigações cardinais (ver § 6.2).
Seguro: A Gosign mantém seguro de responsabilidade civil profissional e empresarial conforme o mercado. Comprovação disponível mediante solicitação.
Prescrição: Dois anos; não aplicável em caso de dolo, culpa grave ou danos pessoais.
§ 12 Reclamações por defeitos (garantia)
Prazo de garantia: 12 meses a partir da aceitação para defeitos de qualidade e de título.
Os defeitos devem ser comunicados sem demora em forma textual. Correção mediante reparo ou substituição.
Fracasso após duas tentativas: Redução do preço ou resolução do contrato.
Sem garantia por desvios insignificantes ou perturbações causadas pelo cliente.
Erros em software de código aberto ou de terceiros não constituem defeito dos serviços da Gosign, desde que corretamente integrados.
A garantia para Componentes de Plataforma está sujeita às restrições do § 7.8 (modificações do cliente).
Em relações contratuais de trato sucessivo: Aplicam-se as disposições legais para contratos de serviço/locação.
§ 13 Proteção de dados e tratamento de dados
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.
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.
A Gosign atua como operador de dados (Art. 28 RGPD). As partes celebrarão um contrato de tratamento de dados (AVV/DPA).
A Gosign aceita também contratos de tratamento de dados fornecidos pelo cliente, desde que conformes com o RGPD.
A Gosign implementa medidas técnicas e organizacionais adequadas (Art. 32 RGPD).
Suboperadores com consentimento geral, desde que contratualmente vinculados a um nível equivalente de proteção de dados.
Data Residency: 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.
Em caso de violações de dados: Notificação imediata e cooperação nas obrigações de comunicação.
§ 14 Confidencialidade
Ambas as partes tratam informações confidenciais com estrita confidencialidade.
Divulgação: Apenas com critério de necessidade de conhecimento (need-to-know), a funcionários sujeitos a obrigações de confidencialidade.
Padrão de proteção: 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.
Duração: 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.
Devolução e destruição: Mediante solicitação, no mais tardar com o término do contrato.
Uso como referência: A Gosign somente poderá utilizar o nome e logotipo do cliente como referência com o consentimento prévio por escrito do cliente.
§ 15 Duração do contrato e rescisão
15.1 Contratos de projeto encerram-se com a aceitação da última entrega e o pagamento integral.
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.
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.
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.
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.
§ 16 Conformidade, certificações e representação dos trabalhadores
16.1 Cert-Ready: 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.
16.2 Representação dos trabalhadores e cogestão: 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.
16.3 Conformidade com sanções: A Gosign confirma que não mantém relações comerciais com pessoas, entidades ou estados sancionados.
16.4 Sustentabilidade: A Gosign considera aspectos de eficiência energética na seleção de infraestrutura. Informações disponíveis mediante solicitação.
§ 17 Controle de exportação
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.
§ 18 Força maior
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.
§ 19 Disposições finais
Direito aplicável: Direito alemão, com exclusão da Convenção das Nações Unidas sobre Contratos de Compra e Venda Internacional de Mercadorias (CISG).
Foro competente: Hamburgo, Alemanha (para comerciantes e pessoas jurídicas).
Idioma do contrato: Alemão. Versões em outros idiomas servem à cooperação internacional; em caso de dúvida, prevalece a versão alemã.
Versionamento: Estes TCG possuem número de versão e data. A versão vigente está disponível em gosign.de/de/agb/.
Alterações em forma textual. Alterações nos TCG com 6 semanas de antecedência; prazo de oposição de 4 semanas.
Cessão: 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.
Cláusula de salvaguarda. Prevalência dos acordos individuais.
--- 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 (`
`) e proteger tabelas contra quebra com `
`.
## 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 `
`.
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 `` e nem `srcset`. Todo dispositivo carrega a mesma imagem, seja desktop (1920px) ou smartphone (375px). Solução: Swiper e Splide suportam `srcset` e `` 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: `` para uma nova página, `` para uma célula de texto, `` para uma imagem, `` 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 `` 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 `` em um SVG), os hotspots são elementos SVG (``, ``, ``) com atributos `data-` e event handlers. Os conteúdos de tooltip são lidos via JavaScript de um bloco `"), 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 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 `` 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 ``.
## 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 `` 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 ``, 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 `` com as classes CSS correspondentes é escrito no richtext: ``) 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 `` existentes no conteúdo por referências `