IA que age sem rastro é IA que vira passivo

Quem pediu.

O que foi feito.

Quando.

Com qual permissão.

Cada ação que o agente de IA do F7 KORE executa cai num registro que responde essas quatro perguntas. Não é log opcional pra debug; não é dashboard pra diretoria; é trilha de auditoria à prova de adulteração — qualquer alteração fica detectável —, verificável por qualquer auditor sem depender da F7, desde o primeiro dia da implantação.

Esse parágrafo soa óbvio. Não é. A maioria das integrações de IA dentro de operação industrial hoje está sendo feita sem isso, ou com isso parcialmente — e a conta vai chegar.

A pergunta do auditor não mudou

Auditor não pergunta “vocês têm IA?”. Pergunta:

• “Quem decidiu abrir esta OS de manutenção?”
• “Qual evidência você tem de que o lote 4471 passou pelo check de liberação?”
• “Onde está o registro de quem aprovou a alteração no procedimento?”
• “Como você comprova que esse dado pessoal só foi acessado por quem tinha permissão?”

Essas perguntas são antigas. O que mudou é o sujeito da frase.

Quando o sujeito é uma pessoa, a resposta vem por assinatura, email, preenchimento de formulário, log de acesso individual. O ecossistema todo foi construído pra que pessoa-deixe-rastro.

Quando o sujeito é uma IA, a resposta default — sem desenho — é “não tenho”. E “não tenho” é uma resposta ruim em qualquer auditoria — interna, de cliente enterprise, de certificadora, de vigilância sanitária — e pior ainda numa disputa judicial. O art. 20 da LGPD já dá ao titular o direito de pedir revisão de decisão automatizada, e o PL 2338/2023, o marco da IA em tramitação, vai na mesma direção. Sem rastro, não há o que revisar.

IA que age sem rastro é IA que vira passivo — porque toda decisão dela vira suposição em retrospecto.

O que log de debug não é

Log de debug existe em qualquer sistema sério. Servidor que processa requisições gera log; aplicação que chama serviço gera trace; banco que recebe query gera audit log de DBA.

Mas log de debug é construído pra diagnosticar problema técnico. Tem campos como “level: warn”, “stack trace”, “request id”, “duration ms”. É linguagem de engenheiro pra engenheiro.

Trilha de auditoria é outra coisa. Foi construída pra responder pergunta de auditor — então tem campos como “ator”, “ação”, “recurso afetado”, “permissão exercida”, “justificativa quando aplicável”, “carimbo de tempo encadeado”. É linguagem de governança pra governança.

A diferença prática:

• Log de debug pode ser apagado pra economizar disco. Audit trail não.
• Log de debug pode ter retenção de 30 dias. Audit trail tem a retenção que o regime da empresa pede — em geral, anos.
• Log de debug pode ser editado em produção pra reformatação. Audit trail é append-only por design.
• Log de debug não amarra à identidade real do usuário com forte garantia. Audit trail amarra.

Trocar log de debug por audit trail “depois que precisar” é projeto de seis meses no melhor caso e re-arquitetura no pior. Por isso IA aplicada à operação industrial precisa nascer com a coisa certa desde o primeiro dia.

Permissão como design fundacional

Tem um corolário menos óbvio do audit trail: ele só faz sentido se a permissão que ele registra for real.

Se a IA tem “acesso de admin” porque foi mais fácil configurar, o audit trail vai registrar “o agente executou OS 8839 com permissão admin” — e isso não responde nenhuma pergunta de auditor. Audit trail só vira evidência quando ele registra a permissão do humano que acionou, não a permissão da IA.

No F7 KORE isso é fundação:

• O agente de IA nunca tem permissão própria. Toda ação dele é exercida com a permissão do usuário que o acionou.
• Se o operador da L2 não pode aprovar OS acima de R$ 5 mil sem supervisor, o agente também não aprova — a aprovação vai pro supervisor.
• Se o usuário não tem permissão pra ler um dado pessoal específico, o agente também não lê — mesmo que a função “ler dado pessoal” exista no catálogo.
• A cada ação executada, o audit trail registra: o usuário, a permissão que ele tinha, o recurso afetado, a justificativa quando aplicável.

Isso não é overhead. Isso é o que separa IA aplicada à operação industrial de “IA generativa que te ajuda” — porque operação industrial real exige governança real, e governança real exige que cada ação seja imputável a um humano com permissão verificável.

O que isso significa pra arquitetura

Trilha de auditoria de verdade não é coisa que se cola em cima de arquitetura existente. Ele precisa estar no kernel:

• Banco transacional com retenção configurável por classe de evento.
• Identidade amarrada a SSO real (não usuário compartilhado de serviço).
• Modelo de permissão declarativo (RBAC + segurança em nível de linha por empresa) que a camada de IA lê na hora de cada ação, não em tempo de configuração.
• Trilha encadeada por hash, com âncoras periódicas em armazenamento imutável — qualquer adulteração fica detectável, e um auditor verifica fora da plataforma.
• Exportabilidade pra formato que auditor consome — não dump de log de aplicação.

No F7 KORE essas cinco camadas moram no mesmo núcleo, sobre o InterSystems IRIS — o mesmo motor de sistemas críticos de finanças e saúde. Não é stack montada com cinco serviços diferentes; é uma plataforma que combina banco, motor de fluxo e auditoria nativa no mesmo processo, com o volume e a latência que isso exige.

Não dá pra fazer isso colando endpoint de LLM em cima do ERP. Foi por isso que construímos o motor sobre essa base: banco, fluxo, permissão e trilha no mesmo núcleo, em vez de cinco serviços costurados — rodando na Google Cloud em São Paulo ou on-premises, com a IA que a empresa escolher.

Confiança não é discurso. É arquitetura.

Cliente industrial que conversa com a gente sobre IA aplicada à operação tem a mesma pergunta, em variações: “como eu confio que isso não vai virar problema de compliance?”

A resposta honesta não vem em forma de promessa. Vem em forma de arquitetura — auditável desde o primeiro registro, com a permissão do humano em toda ação, com uma trilha à prova de adulteração, ancorada em armazenamento imutável, que continua de pé depois de uma falha de operação ou da saída de um funcionário — e que qualquer auditor verifica sem depender da F7.

É isso que o F7 KORE entrega como fundação. Não como add-on.

---

O F7 KORE é desenvolvido pela F7 KORE SOFTWARE LTDA, parceira da InterSystems, com atuação em ambientes regulados — incluindo auditoria sanitária em caso real. Como funciona a trilha à prova de adulteração, que um auditor verifica sem depender da F7, está na página de FAQ.

Se você opera indústria de porte médio-grande, com requisito regulatório real, e quer entender como uma trilha à prova de adulteração muda o desenho da sua operação — fale com a gente.