DEV Community: Anderson Chipak

O EU AI Act pode alcançar sua empresa sem escritório na Europa

Anderson Chipak — Wed, 11 Nov 2026 20:24:38 +0000

O EU AI Act pode alcançar sua empresa sem escritório na Europa

O endereço da sede não é o que decide

Sou auditor de sistemas críticos, e a primeira coisa que preciso desfazer quando alguém me pergunta se o EU AI Act vale para uma empresa brasileira é essa ideia de que a lei pede escritório na Europa. Não pede. O Artigo 2 define o escopo territorial por três gatilhos, e nenhum deles é o endereço da sede.
O primeiro gatilho: você coloca um sistema de IA ou um modelo de propósito geral no mercado europeu, direto ou por distribuidor. Se sim, você é fornecedor sob o regulamento, esteja onde estiver. O segundo, mais esquecido: o resultado produzido pelo seu sistema é usado dentro da União Europeia, mesmo que a venda, o contrato e o pagamento aconteçam inteiramente fora dela. O critério é o uso do resultado, não o local da transação.
Existe uma terceira situação que não está escrita no Artigo 2, mas produz o mesmo efeito na mesa de quem decide: você fornece um modelo, um dataset ou um componente que um cliente europeu integra num sistema que ele próprio coloca no mercado da União. Quem está formalmente no escopo, nesse caso, é o cliente, não você. Só que ele, para cumprir a própria obrigação de due diligence, vai exigir de você evidência de conformidade por contrato.

O contrato chega antes da multa

Aqui está o ponto central que eu vejo confundido com mais frequência: para quem opera fora da União Europeia, o EU AI Act funciona por pressão contratual antes de funcionar por fiscalização direta. A Comissão Europeia fiscaliza quem está na União. Quem está fora sente o regulamento através de quem compra.
Isso não torna o risco menor. Torna o risco mais difícil de nomear, porque ele chega disfarçado de cláusula contratual, não de autuação. E o custo real quase nunca é a multa do Artigo 99, que chega a 7% do faturamento global no papel, mas que a Comissão só executa fora da União por cooperação internacional, quando existe bem ou representante para alcançar. Cobrar isso de quem não tem nenhum dos dois é outra história. O custo que eu vejo acontecer de verdade é o cliente europeu que não renova porque a due diligence não teve resposta, ou o fornecedor que perde a concorrência porque o concorrente já tinha a política e o inventário documentados.

O prazo mudou, e isso também muda a conversa

O terceiro ponto que entra em toda decisão sobre isso é o calendário, porque ele mudou em 2026. O Regulamento (UE) 2026/1744, o Digital Omnibus, entrou em vigor em 27 de julho de 2026 e empurrou a aplicação plena das obrigações de alto risco do Anexo III, sistema autônomo, de agosto de 2026 para dezembro de 2027. Para IA embutida em produto já regulado, o prazo foi para agosto de 2028. As obrigações de transparência do Artigo 50 não foram adiadas, e isso costuma passar batido em quem só leu a manchete do adiamento.
Eu trataria esse prazo extra como tempo para organizar inventário e política com calma, não como motivo para adiar o começo do trabalho. Quem só começa a levantar os próprios sistemas em 2027 vai correr o mesmo risco de sempre, só que com menos tempo de sobra.

A quarta situação: quem distribui modelo sem saber quem vai usar

Existe um caso que eu trato separado dos outros três, porque a confusão nele é maior: o fornecedor de modelo de propósito geral, o chamado GPAI, que licencia o próprio modelo para quem quiser integrar, sem saber de antemão quem vai usar o quê nem onde. Para esse fornecedor, o Artigo 2 se aplica no momento em que ele coloca o modelo no mercado europeu, por canal próprio ou por qualquer distribuidor, independente de quantos passos existam entre ele e o usuário final dentro da União. Uma empresa brasileira que licencia um modelo de linguagem para qualquer integrador que queira pagar por ele pode descobrir, meses depois, que uma fração relevante do uso comercial vem de integradores europeus que nem existiam quando o contrato original foi fechado.

EU AI Act e PL 2338: dois calendários diferentes

Confundir essas duas leis leva a decisão errada nos dois sentidos. O EU AI Act já está em vigor, por fases, desde 2024, com o efeito extraterritorial que descrevi acima. O PL 2338 foi aprovado pelo Senado em dezembro de 2024 e, em novembro de 2026, continua tramitando na Câmara dos Deputados, sem data definida para votação em plenário. Nada nele obriga ninguém hoje, porque projeto de lei não é lei. Quem só olha o calendário brasileiro para decidir quando organizar a própria operação de IA está lendo o calendário errado: o que já cobra por contrato, hoje, é o europeu.

O exemplo que mostra o mecanismo inteiro

Uma empresa brasileira de médio porte vende um modelo de classificação de risco para um banco europeu, que o integra num sistema de concessão de crédito classificado como alto risco pelo próprio AI Act. O banco está diretamente no escopo. A empresa brasileira não está, pelo Artigo 2. Mas recebe do banco um questionário de due diligence com data de resposta: documentação de dados de treino, registro de testes, avaliação de viés.
Nenhuma multa europeia chega à empresa brasileira nesse cenário. O contrato chega primeiro, e decide se o pedido do ano seguinte existe. É esse mecanismo, repetido em setores diferentes, que faz o EU AI Act alcançar quem nunca vendeu diretamente para a Europa.

O que eu faria antes de qualquer coisa

Antes de discutir multa ou advogado europeu, eu começaria pelo levantamento: listar os sistemas de IA em uso na empresa, marcar quais produzem resultado consumido na União Europeia ou alimentam cliente de lá, e só depois decidir se o esforço é jurídico, contratual ou os dois. Isso vale tanto para quem já sabe que vende para a Europa quanto para quem acha que não vende e nunca checou.
Se um cliente europeu te mandasse hoje um questionário de due diligence sobre IA, a lista de sistemas já estaria pronta, ou alguém precisaria descobrir na hora quais deles decidem algo que chega lá?
Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/eu-ai-act-empresa-brasileira/

Quando a auditoria interna de IA vira teatro de calendário

Anderson Chipak — Mon, 09 Nov 2026 20:15:17 +0000

Quando a auditoria interna de IA vira teatro de calendário

O número que a norma não dá

Não existe um número de auditorias por ano escrito na ISO 42001. Sou auditor de sistemas críticos, e essa é a primeira coisa que preciso desfazer quando alguém me pergunta de quanto em quanto tempo deve auditar os próprios sistemas de IA. A cláusula 9.2 pede três coisas: intervalos planejados, imparcialidade de quem audita e evidência documentada do que foi verificado. Ela não separa sistema de alto risco de sistema trivial. Essa separação é trabalho de cada empresa, não da norma.
Isso incomoda quem queria uma resposta pronta. É a resposta certa mesmo assim: cláusula genérica não decide pelo parque de sistemas de ninguém.

Por que calendário fixo é teatro, não controle

Marcar "auditoria de IA em dezembro", todo ano, sem olhar risco, cumpre a forma da cláusula 9.2 e falha no conteúdo dela. Um sistema que mudou de fornecedor em março fica sem revisão por nove meses, e ninguém percebe até o incidente aparecer.
A ISO 19011, atualizada em maio de 2026, substitui a edição de 2018 e reforça exatamente esse ponto: planejamento de auditoria baseado em risco, não em aniversário da última visita. A revisão também trata auditoria remota e híbrida como método normal, e passa a cobrar competência em tecnologia da informação de quem audita. Parte da evidência de um sistema de IA vive em log, em painel de monitoramento e em repositório de versão de modelo, não em papel. Quem não sabe ler essas três fontes audita só a política escrita, nunca o sistema de verdade.
O NIST AI RMF chega na mesma pergunta pelo lado do risco, não do calendário. A função Govern pede que a empresa defina, por escrito, a frequência de revisão de cada sistema como parte do próprio processo de gestão de risco, não como item solto de auditoria.

A régua de três faixas que eu uso

Eu organizo a frequência por risco em três faixas, e trato os números como premissa minha, sem fonte de mercado que os valide:

Sistema que decide sozinho sobre crédito, contratação ou saúde: faixa trimestral.- Sistema que apoia decisão humana, mas pesa na recomendação final: faixa semestral.- Ferramenta de produtividade interna, sem efeito direto sobre terceiro: faixa anual, junto com a revisão completa do sistema de gestão. Essa régua muda quando o sistema muda. Modelo retreinado todo mês com dado novo do cliente não espera o calendário anual chegar para ser revisado de novo. Três eventos, além do calendário, deveriam disparar uma auditoria fora de hora: troca de fornecedor do modelo, mudança relevante na base de dados de treino, e qualquer incidente relatado por quem usa o sistema no dia a dia. Esperar a próxima data agendada nesses casos custa caro. Se o incidente vira pauta do comitê de auditoria antes de a empresa ter revisado o sistema por conta própria, a pergunta que sobra não é mais técnica. É por que ninguém olhou antes. ## O escopo que a maioria audita pela metade O escopo da auditoria interna de sistemas de IA cobre cinco frentes, e a maioria das empresas que eu vejo audita só a primeira: inventário de onde a IA decide ou influencia algo, controle sobre a qualidade e a origem do dado, registro de quem aprovou o uso daquele sistema, due diligence do fornecedor do modelo, e evidência de supervisão humana no ponto em que a decisão afeta alguém de fora da empresa. Um cenário que já vi se repetir em formatos diferentes: uma auditoria de IA revisa o modelo de triagem de crédito e aprova, porque a taxa de acerto está dentro do esperado. Uma auditoria de controle interno, meses depois, revisa o mesmo processo e reprova, porque não existe registro de quem autorizou colocar aquele modelo em produção. As duas auditorias estavam certas. Cobriram escopos diferentes do mesmo sistema. Vi o equivalente fora de IA numa auditoria de SOX que conduzi numa mineradora, aprovada pela Ernst & Young sem ressalvas. O que sustentou a aprovação não foi o sistema em si. Foi o rastro de quem decidiu, testou e aprovou cada mudança, com redução de 90% no tempo de troubleshooting como efeito colateral. Sistema de IA sem esse mesmo rastro reproduz, com outro nome, o problema que a auditoria tradicional já resolveu há tempos. ## Quem audita sem virar o próprio fiscal A cláusula 9.2 exige imparcialidade: quem auditou a implantação de um sistema não audita a própria implantação depois. O modelo de três linhas que o IIA aplica à IA ajuda a separar papéis. A primeira linha é quem opera o sistema no dia a dia. A segunda é o comitê de risco, que define política e monitora. A terceira é a auditoria interna, independente das outras duas. Empresa pequena, sem estrutura para três linhas separadas, ainda cumpre a imparcialidade: basta que quem audita um sistema não seja quem aprovou a entrada dele em produção. Isso evita o conflito mais comum, que é o próprio dono do projeto de IA assinando embaixo a auditoria do próprio projeto. Se a mesma pessoa precisa acumular as duas pontas por falta de equipe, eu registraria essa limitação por escrito, como controle compensatório. ## O que acontece quando essa auditoria não existe Quem primeiro percebe o vácuo costuma ser de fora: um cliente grande pedindo evidência em due diligence, o auditor externo da certificação, ou um incidente que vira pauta do conselho antes de qualquer comitê interno ter revisado o sistema envolvido. Nenhum desses três cenários dá tempo de montar o programa de auditoria depois que a pergunta já chegou. ## Conclusão Antes de agendar a primeira auditoria interna de IA, eu monto o inventário de sistemas com dono nomeado, classifico o risco por sistema, não por área inteira, defino quem audita cada um sem conflito com quem implantou, registro a frequência por faixa de risco com data da próxima revisão, e listo o que cada auditoria verifica: dado, aprovação, fornecedor, supervisão humana. Se a sua empresa já tem uma data fixa de auditoria de IA marcada no calendário anual, vale a pergunta inversa: ela foi escolhida porque é quando o risco pede, ou porque é quando sobrou espaço na agenda do comitê? Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/auditoria-interna-de-ia-frequencia-e-escopo/

Quando o contrato diverge da proposta, qual documento vale?

Anderson Chipak — Thu, 05 Nov 2026 12:06:27 +0000

Quando o contrato diverge da proposta, qual documento vale?

O erro que encontrei dentro da minha própria operação

Eu tinha publicado uma proposta comercial de 24 páginas e já entregado a um cliente. Meses depois, sentei para escrever o contrato em cima dela. Reli o próprio documento, mas a leitura parou na página 11 sem eu perceber.
Voltei para as páginas 12 a 24 mais devagar. Lá estava um sistema de cobrança completo, já publicado por mim, que divergia em 16 pontos do que eu tinha acabado de escrever no contrato. Cinco deles graves. O mais caro: o contrato definia que uma unidade de capacidade equivalia a uma hora de trabalho. A proposta publicada nunca disse isso. Ela precificava um site em 120 unidades dentro de um ciclo de 100.
Corrigi treze dos 16 pontos no mesmo dia. A tabela que eu tinha escrito no contrato foi descartada e refeita sobre a que já estava publicada.
O que torna esse caso útil não é o erro em si. É que não havia fornecedor nenhum do outro lado para discordar. Era documento meu contra documento meu, dentro da mesma operação. E foi por isso que a resposta apareceu sem ruído: quando o que alguém já recebeu diverge do que foi escrito depois, vale o que ele recebeu.

A proposta obriga quem a fez, com ou sem CDC envolvido

O Código Civil brasileiro diz, no artigo 427, que a proposta de contrato obriga o proponente, salvo se o contrário resultar dos termos dela, da natureza do negócio ou das circunstâncias do caso. Isso vale para qualquer contrato, entre qualquer tipo de parte, sem precisar que ninguém seja classificado como consumidor.
Se você manda um orçamento com prazo, preço e o que está incluso, e a outra parte aceita, esse documento já obriga antes de existir qualquer contrato assinado depois. Vale nos dois sentidos: se você é quem recebe a proposta de um fornecedor, o que ele prometeu por escrito não desaparece porque o contrato final ficou mais vago.
Quando a relação é de consumo, a lei aperta a régua. O artigo 30 do Código de Defesa do Consumidor diz que toda informação ou publicidade suficientemente precisa sobre um serviço integra o contrato que vier a ser celebrado. O artigo 48 vai além e inclui o que foi escrito informalmente: declarações em escritos particulares, recibos e pré-contratos também vinculam quem presta o serviço. Uma mensagem de WhatsApp com o preço combinado, se for precisa o suficiente, já entra nessa régua.
Essa obrigação tem limite. O artigo 428 detalha que uma proposta feita a alguém presente, sem prazo definido, e não aceita imediatamente, deixa de valer. Um orçamento verbal numa reunião, sem resposta na hora, não persegue ninguém seis meses depois. Um orçamento por escrito, com prazo declarado, continua valendo enquanto esse prazo não vencer.

A exceção: quando o contrato posterior pode, sim, prevalecer

O primeiro papel não ganha só por ser o primeiro. Um contrato pode mudar validamente o que a proposta previa, desde que a mudança seja consciente, combinada, e as duas partes concordem sabendo o que estão trocando.
Em uma contratação da minha própria carteira, o contrato padrão previa multa de rescisão, multa de justa causa, multa de mora, multa de aliciamento e reajuste anual automático. O cliente objetou cada cláusula, uma por vez, no mesmo dia. O contrato fechou com quatro concessões simultâneas: preço 30% abaixo da tabela publicada, capacidade integral mesmo assim, nenhuma multa de espécie alguma e valor fixo sem reajuste. Registrei por escrito que aquilo era exceção negociada naquele contrato específico, não o novo padrão.
A diferença entre esse caso e o da proposta de 24 páginas é a consciência. Ali, as duas partes sabiam exatamente o que estava sendo trocado. Na outra, o contrato divergiu porque eu tinha deixado de ler oito das 24 páginas que eu mesmo tinha publicado antes.

Um exemplo fora do meu próprio escritório

Pense numa dentista contratando uma agência para o Instagram da clínica. A proposta prometia quatro publicações por semana e relatório mensal. O contrato, redigido depois pela agência, falava em "produção de conteúdo conforme planejamento", sem número nenhum.
O número que a proposta prometeu continua obrigando a agência pelo artigo 427, porque esse artigo nunca dependeu de ninguém ser consumidor. Mesmo que essa dentista precise provar vulnerabilidade técnica para contar como consumidora em algum caminho mais específico do CDC, o compromisso civil geral já está de pé.

O que fazer antes de discutir qual documento vale

Nenhuma dessas regras resolve nada se os dois documentos não estiverem guardados e datados. Quem só guarda lembrança de uma reunião perde a disputa antes de começar, porque palavra contra palavra não produz prova para um juiz, um Procon ou uma mediação examinar.
A sequência prática que uso agora: reler os dois documentos lado a lado, item por item. Marcar cada ponto de divergência. Separar o que é erro de quem escreveu depois do que foi mudança combinada e registrada. Pedir por escrito, antes de discutir valor ou prazo, qual documento prevalece. Só depois decidir se vale renegociar, com a mudança nova também registrada.

Conclusão

O documento que alguém já tem na mão não vira rascunho só porque outra pessoa escreveu algo diferente num papel mais recente. "Assinado por último" é hábito de mercado, não é lei. A régua que corrigiu meu próprio contrato por cima de oito páginas não lidas é a mesma que vale para qualquer proposta que você já mandou, ou já recebeu.
Este artigo é uma versão condensada de uma análise mais completa, com as citações legais inteiras e um checklist, que publiquei em https://chipak.com.br/artigos/vence-o-que-voce-ja-recebeu-nao-o-que-foi-escrito-depois

O risco de IA que o CFO assina sem saber que assinou

Anderson Chipak — Tue, 03 Nov 2026 20:17:08 +0000

O risco de IA que o CFO assina sem saber que assinou

O erro que preocupa menos que a assinatura

O modelo de IA errar não é o maior risco financeiro de uma empresa hoje. O maior risco é o CFO assinar, sob a Lei Sarbanes-Oxley, a certificação de um controle interno que depende de um sistema de IA generativa que a empresa nunca inventariou nem testou formalmente como controle. A consequência não é hipotética: multa, reapresentação de balanço, ou um apontamento do comitê de auditoria que chega sem aviso, porque ninguém sabia que a IA já decidia naquele processo.
O ponto de partida é quase sempre o mesmo em qualquer empresa que eu examino: ninguém sabe, com precisão, quantos sistemas de IA generativa já decidem alguma coisa dentro da área financeira, do fechamento ao crédito.

Por que isso virou pauta do CFO, não só do CIO

Durante anos, todo risco ligado a tecnologia caía automaticamente no colo do CIO. O risco de IA quebrou essa divisão. Um levantamento recente da Deloitte, com 200 CFOs de empresas norte-americanas com faturamento acima de US$ 1 bilhão, mostra o motivo: quase um em cada cinco desses CFOs (19%) já diz carregar a maior responsabilidade pela governança de IA na própria empresa, mais do que qualquer outra função isolada. Equilibrar a pressão para usar IA rápido com o risco que ela carrega é o maior desafio citado, por 59% deles.
A IA generativa entrou primeiro pelo braço mais rápido de adotar, geralmente marketing ou atendimento. O uso que preocupa o CFO é outro: previsão de fluxo de caixa, triagem de crédito, conciliação automática, redação de nota fiscal e de parecer contábil. Cada um desses usos toca, direta ou indiretamente, um controle interno que o CFO já certifica pessoalmente todo trimestre, sob risco pessoal, não só reputacional.

Quem no conselho responde pelo risco

Hoje, formalmente, costuma ser ninguém sozinho. A Lei Sarbanes-Oxley já resolve uma parte da pergunta para empresa listada nos EUA, ou com obrigação equivalente: o CEO e o CFO assinam pessoalmente, a cada relatório trimestral e anual, a certificação de que avaliaram o controle interno e identificaram qualquer fraqueza material. Se um desses controles depende de um sistema de IA sem inventário, sem teste e sem dono, essa assinatura vira uma aposta.
A ISO 42001 ataca o mesmo vácuo por outro ângulo: exige que a empresa nomeie, por escrito, quem responde por cada papel dentro do sistema de gestão de IA, não só pelo risco do modelo, mas pela decisão de usar IA num processo determinado. Eu recomendo tratar o comitê de risco como dono formal dessa governança, com o CFO dentro dele por causa do impacto financeiro e o jurídico por causa da exposição regulatória.

O inventário antes do orçamento

Já vi orçamento de governança de IA ser aprovado sem que ninguém soubesse quantos sistemas de IA generativa a empresa já usa. Isso inverte a ordem certa: o inventário vem antes do orçamento, porque sem ele o CFO está precificando um risco que ainda não mediu. Antes de orçar qualquer coisa, eu pediria ao comitê de risco:

lista completa de sistemas de IA generativa em uso na área financeira, com dono de negócio nomeado;- para cada sistema, se a decisão é automática ou só apoia quem decide;- se o sistema toca algum controle certificado sob SOX ou equivalente;- due diligence documentada de cada fornecedor de modelo usado no financeiro;- data da última avaliação de impacto de cada sistema de risco médio ou alto. Levantar esse inventário, por sistema, com dono, finalidade e classificação de risco, costuma consumir de 20 a 40 horas de trabalho qualificado numa área financeira de porte médio, com cinco a quinze sistemas em uso. É uma estimativa minha, sem fonte de mercado atrás dela. ## O calendário que não pode ser ignorado Toda empresa brasileira que vende para a União Europeia, ou que depende de um fornecedor de IA que vende lá, herda parte desse calendário dentro do próprio contrato, mesmo sem operação na Europa:
agosto de 2026: o Artigo 50 do EU AI Act passa a exigir aviso quando o conteúdo é gerado por IA;- dezembro de 2027: obrigações plenas do EU AI Act para sistema de IA de alto risco autônomo;- agosto de 2028: obrigações plenas para IA embutida em produto já regulado. O Regulamento (EU) 2026/1744 não cancelou a obrigação de alto risco, só empurrou o prazo. CFO que orça governança de IA como gasto de um ano só vai reorçar duas vezes sem necessidade, porque o calendário mudou de data, não de direção. No controle certificado sob SOX, o problema real é a frequência de revisão: um modelo retreinado todo mês com um controle testado uma vez por ano deixa a avaliação de impacto do trimestre passado descrevendo um sistema que já não existe mais daquela forma. ## O que a ISO 42001 realmente resolve A norma organiza o que precisa existir, política, inventário, avaliação de impacto, controle de dado e de fornecedor, nas mesmas cláusulas de sistema de gestão que qualquer auditor já reconhece de outras certificações. Eu vi esse mecanismo de perto numa auditoria de SOX que conduzi numa mineradora, aprovada pela Ernst & Young sem ressalvas: a redução de 90% no tempo de troubleshooting não veio de tecnologia nova, veio de rastreabilidade documentada. É a mesma peça que falta hoje na maioria dos inventários de IA que eu examino. Perguntar ao fornecedor "vocês são certificados ISO 42001?" não fecha a exposição do CFO. A due diligence de fornecedor é um controle dentro da norma, não substituto dela: a responsabilidade pelo uso do modelo na operação financeira continua sendo de quem o usa. ## Por onde eu começaria, se fosse o CFO Pelo inventário, antes de qualquer política bonita ou comitê novo, porque nenhuma decisão de risco tem resposta sem saber quantos sistemas existem e quem é dono de cada um. Depois, eu classificaria risco por proximidade do controle certificado: sistema que toca fechamento, crédito ou nota fiscal entra primeiro na fila de avaliação de impacto, sistema de produtividade interna entra depois. Só então eu discutiria orçamento. Se o comitê de auditoria perguntasse amanhã quantos sistemas de IA generativa decidem algo dentro do financeiro hoje, a resposta sairia de um inventário, ou de uma estimativa de memória? --- Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/risco-de-ia-para-o-cfo/

O fornecedor de IA jurídica não tem o mesmo interesse que você em revisar o que ela decide

Anderson Chipak — Sun, 01 Nov 2026 12:07:23 +0000

O fornecedor de IA jurídica não tem o mesmo interesse que você em revisar o que ela decide

O padrão que se repete entre um plugin de loja e uma ferramenta jurídica

Em abril um cliente me mandou, lado a lado com a minha proposta, a de um concorrente. Queria saber se eu conhecia os plugins que esse outro profissional recomendava no lugar dos meus. Segundo ele, eram "100% confiáveis e gratuitos", porque o criador ganhava por fora, pela venda que o plugin empurrava.
Respondi que sim, conhecia o modelo, e expliquei por que tanta gente cria peça de loja sem a mínima segurança assim: o fornecedor lucra com o volume que o plugin gera, não com a qualidade dele. Ninguém tinha mentido sobre o preço. A mentira estava em "100% confiável".
Troque plugin por ferramenta de IA jurídica, e checkout por peça com o nome do advogado embaixo, e o padrão é o mesmo. Em outubro de 2026 a Ordem dos Advogados do Brasil publicou uma resolução tratando exatamente desse tipo de promessa, depois de dois processos que mostram o tamanho que ela chega a ter quando levada longe demais.

O que a Resolução 16/2026 realmente autoriza

A Resolução 16/2026, publicada em 13 de outubro pelo Conselho Federal da OAB, não regula o advogado que usa inteligência artificial no próprio trabalho. Regula a relação entre a OAB e a empresa que vende a ferramenta. Ela proíbe a empresa de sugerir, em qualquer peça de publicidade, que o software substitui o advogado ou que tem aprovação institucional da entidade.
Isso veio depois de uma decisão de agosto, quando o Conselho Pleno autorizou por unanimidade medidas judiciais contra empresas de IA que exercessem atividade privativa da advocacia. A resolução de outubro é a ferramenta de negociação, por meio de Termo de Ajustamento de Conduta. A decisão de agosto é o que autoriza processar quando a negociação não resolve, e a própria resolução deixa escrito que firmar um TAC não significa que a OAB certifica ou recomenda a ferramenta envolvida.

Insight 1: o incentivo do fornecedor nunca esteve alinhado com a sua revisão

Com ferramenta de IA jurídica, a moeda trocou de comissão de venda para tempo de uso e renovação de contrato. Quanto mais capaz de decidir sozinha a ferramenta parecer, menos revisão o escritório sente que precisa fazer, e mais rápido assina de novo no mês seguinte. Isso não quer dizer que todo fornecedor minta. Quer dizer que o incentivo dele, por padrão, não é o seu interesse de conferir cada saída antes de assinar.
O caso que corre contra a empresa Talisman AI, responsável pela ferramenta Enter, mostra o tamanho disso quando ninguém questiona. A ferramenta processa mais de 300 mil casos judiciais por ano para mais de 40 empresas, automatizando desde o registro do processo até a redação de peças. A OAB/SP alega que cada etapa possível de um processo é tratada por um agente de inteligência artificial antes de qualquer participação humana, e pede multa diária de R$ 10 mil por violação de ordem de suspensão de publicidade.
A OAB/RJ, no mesmo mês, venceu no Superior Tribunal de Justiça contra uma plataforma diferente, que vendia petição pronta por R$ 20 sem participação de advogado algum. Duas empresas, dois modelos de negócio, o mesmo padrão de fundo.

Insight 2: o fornecedor que promete ter eliminado o risco está inflando o próprio produto

Os fornecedores de três ferramentas comerciais de pesquisa jurídica dos Estados Unidos anunciaram métodos capazes de eliminar ou produzir resultado livre de alucinação. Um estudo de 2025, publicado no Journal of Empirical Legal Studies, testou essa promessa com mais de 200 perguntas jurídicas, elaboradas e registradas antes de qualquer resposta ser vista.
Resultado: as três ferramentas alucinaram entre 17% e 33% das vezes. Numa categoria de pergunta específica, sobre o próprio cerne de uma decisão judicial, a taxa de erro chegou a 75%. Nenhuma das ferramentas era gratuita, nenhuma era vendida como experimental.
Isso não prova que toda ferramenta brasileira de IA jurídica erra na mesma proporção. As ferramentas testadas são de outro mercado, com outra base de jurisprudência. Prova algo mais simples: o fornecedor que afirma ter eliminado esse risco está, pela própria pesquisa que testou a afirmação, inflando o que o produto garante.

Insight 3: a saída não é revisar tudo, é escolher o que nunca entra na amostragem

Existe a objeção óbvia: "preciso do volume que a ferramenta processa, não dou conta de revisar linha a linha". Revisar cada saída por completo anula o motivo de ter contratado a automação. Não revisar nenhuma é o desenho que a OAB está processando agora. No meio das duas fica a amostragem.
Com os próprios números do processo contra a Enter, 300 mil casos por ano divididos pelas mais de 40 empresas clientes dá uma média de 7.500 processos por empresa ao ano, uns 625 por mês. Um escritório nesse patamar que decidisse conferir 10% das saídas ainda teria uns 63 casos por mês passando por revisão humana. A régua que não pode ceder: decisão de estratégia e peça que vai a juízo entram sempre na checagem, nunca entram na fração reduzida. Sorteio não substitui critério.

O que muda pra quem já paga por uma dessas ferramentas

A resolução protege o mercado como um todo. Não troca, sozinha, a responsabilidade pessoal do advogado por nada que saiu com o seu nome. Redigir o rascunho pode ser delegado, inclusive à própria ferramenta. Assinar o conteúdo que vai a juízo com o próprio registro é outra categoria de decisão, e isso já custou multa a quem tratou as duas coisas como a mesma.
Nem toda ferramenta de IA jurídica carrega esse risco no mesmo tamanho. Uma que só busca e organiza jurisprudência, sem sugerir tese nem redigir peça, fica longe do que a Resolução 16/2026 persegue. O risco cresce na proporção da distância entre o que a ferramenta faz e o que a lei reserva à atividade privativa da advocacia.

Antes de renovar o contrato

Cinco perguntas que valem mais do que qualquer folheto de venda: o material da ferramenta já disse ter aprovação da OAB, em algum momento? Existe registro de qual etapa foi feita pela IA e qual foi revisada por um advogado com nome? Você já pediu à ferramenta uma citação específica e foi conferir se ela existe exatamente como apresentada? O contrato permite auditar o que a ferramenta decidiu sozinha nos últimos meses? Se a OAB abrir ação contra esse fornecedor, o contrato prevê algo, ou você só vai saber lendo notícia?

Volto ao cliente de abril. Ele não trocou de fornecedor achando que um software é inofensivo. Trocou achando que "100% confiável" era uma informação, quando era um argumento de venda. A ferramenta de IA jurídica que promete o mesmo tipo de garantia está hoje sujeita a processo por isso.

Este artigo é uma versão condensada de uma análise mais aprofundada, com as cinco referências citadas, a tabela completa e o glossário, que publiquei em https://chipak.com.br/artigos/nenhuma-ferramenta-de-ia-juridica-tem-aprovacao-da-oab

O que um auditor pede, controle por controle, numa auditoria ISO 42001

Anderson Chipak — Fri, 30 Oct 2026 20:18:58 +0000

O que um auditor pede, controle por controle, numa auditoria ISO 42001

Numa auditoria ISO 42001, o auditor não avalia se o seu modelo de IA é bom. Ele avalia se existe um sistema de gestão documentado por trás de cada sistema de IA em produção: política assinada, inventário, avaliação de impacto, controle sobre o dado de treinamento e evidência de que a cláusula 9.2 e o Anexo A foram cumpridos na prática, não só escritos num documento.
Quem se prepara pensando em "o que escrever" quase sempre erra o alvo. O auditor não lê a política, ele testa se ela é seguida, com registro, dono e data.

As duas perguntas que a cláusula 9.2 responde

Simplifico a cláusula 9.2 em duas perguntas, porque é literalmente para isso que ela existe. Primeira: o sistema de gestão de IA cumpre o que a própria empresa prometeu e o que a norma exige? Segunda: esse sistema está implementado de verdade e mantido, não só criado uma vez para passar na primeira auditoria?
A auditoria interna precisa responder as duas, com programa cobrindo todo o ciclo, plano por auditoria, relatório com achado e evidência, e prova de que quem auditou não avaliou o próprio trabalho. Esse último ponto trava empresa pequena: se a mesma pessoa que escreveu a política também assina o relatório que a aprova, a independência exigida pela norma não existe, e é o primeiro ponto que um auditor de certificação testa.

O Anexo A: nove grupos, uma pergunta cada

O Anexo A organiza nove grupos de controle, de A.2 a A.10, e cada um tem um tipo de evidência esperada diferente. O auditor não lê o Anexo A inteiro de uma vez: percorre grupo por grupo pedindo o documento que prova aquele ponto específico.
Em nenhum grupo a resposta certa é "o sistema funciona bem". A resposta certa é "existe prova de que alguém decidiu, revisou e documentou isso". É a diferença entre auditoria de qualidade de modelo, que não é o escopo da 42001, e auditoria de gestão, que é o escopo inteiro da norma.
Uma ordem se repete em quase toda auditoria: o auditor raramente começa pelo A.2, política, porque política bem escrita é fácil de produzir sob pressão, na véspera da visita. Ele começa pelo A.5, avaliação de impacto, porque esse é o controle que mais frequentemente existe só de nome. Uma empresa pode ter política de dez páginas e zero avaliação de impacto preenchida; o contrário eu nunca vi.

O mesmo Anexo A pesa diferente por setor

O texto do Anexo A é igual para qualquer setor, mas o peso da pergunta muda com quem é afetado pela decisão do sistema.
Num banco ou numa empresa de crédito digital, o peso pesado cai sobre A.5 e A.9: o critério usado para negar crédito está documentado de um jeito que resiste a uma reclamação formal? Já vi avaliação de impacto de crédito descrever o modelo em termos técnicos perfeitos e não dizer uma palavra sobre o efeito da decisão sobre quem foi negado.
Na saúde, o peso se desloca para A.4 e A.6: existe gente qualificada para validar clinicamente a recomendação, e controle sobre o que acontece quando o sistema erra com paciente real do outro lado? Na indústria, pesa A.7 e A.10: a origem do dado de sensor está documentada o suficiente para explicar por que o sistema recomendou parar uma linha, e o fornecedor do modelo preditivo responde contratualmente por um erro que causa parada não planejada?
Numa empresa de tecnologia que vende software, o peso recai sobre A.8 e A.10: o cliente recebe informação clara sobre onde a IA entra na decisão que o produto apoia? Empresa de tecnologia costuma documentar bem o que o produto faz, e mal o que ele não garante, que é exatamente o que A.8 cobra.

As cinco perguntas que mais pegam quem não se preparou

Na prática, cinco perguntas derrubam quem chega sem organização:

Quantos sistemas de IA operam hoje na empresa? Rodar essa pergunta num comitê de risco costuma revelar um número maior do que qualquer um esperava.2. O sistema decide ou só apoia quem decide? A ficha técnica quase sempre diz "apoia". O log de uso, quando existe, frequentemente mostra outra coisa.3. Dá para reconstruir quem aprovou o modelo e qual dado alimentou uma decisão específica? É o que decide se a empresa se defende numa disputa judicial.4. Existe due diligence documentada do fornecedor do modelo? A responsabilidade pelo Anexo A.10 é de quem usa o modelo, não só de quem vendeu.5. A avaliação de impacto foi revisada na última mudança relevante, ou ficou congelada na versão da primeira auditoria? ## A ISO 42006: o auditor também está sendo testado Até 2025, quem conduzia a auditoria era avaliado pela regra geral de competência de auditor de sistema de gestão, a mesma usada para ISO 9001. A ISO/IEC 42006:2025 muda isso: fixa requisito específico de competência para o organismo de certificação, não para a empresa auditada. A exigência central é competência coletiva da equipe, não de uma pessoa só: o time precisa somar conhecimento de tecnologia de IA, governança, Anexo A, prática de auditoria e obrigação legal do setor. A norma também muda o cálculo do tempo de auditoria, baseado no número de sistemas de IA, na complexidade, no risco regulatório e na existência de fornecedor terceirizado. Na prática, o organismo de certificação passa a pedir o inventário de sistemas de IA antes de fechar o orçamento da auditoria, não depois. Sem inventário e sem classificação de risco de cada sistema, ele não tem base para calcular quanto tempo a auditoria vai levar nem quanto vai custar. ## Por onde eu começaria Eu começaria pelo inventário de sistemas de IA, antes de qualquer controle do Anexo A, porque nenhuma das perguntas acima tem resposta sem saber quantos sistemas existem e quem é dono de cada um. Depois priorizaria a avaliação de impacto dos sistemas de maior risco, não a política geral, porque é ali que a maioria das empresas descobre a lacuna mais cara de fechar depois. Só então eu trataria do resto do Anexo A, na ordem em que o auditor realmente vai perguntar, não na ordem em que a norma está numerada no papel. Se a sua empresa fosse auditada na próxima segunda-feira, quantas dessas cinco perguntas você conseguiria responder com documento na mão, não de memória? --- Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/o-que-auditor-pergunta-iso-42001/

O que uma IA generativa responde sobre você não tem botão de correção

Anderson Chipak — Thu, 29 Oct 2026 12:11:42 +0000

O que uma IA generativa responde sobre você não tem botão de correção

O problema que 93% das empresas têm e não sabem

Alguém pesquisando um profissional antes de marcar a primeira conversa já não para só no Google. Pergunta direto pro ChatGPT, pro Gemini ou pro que estiver aberto na hora. A resposta que a pessoa recebe não passou pelos olhos do profissional antes de sair.
Um teste publicado em julho de 2026 mediu o tamanho disso. A empresa britânica Searchable perguntou mais de 13 mil vezes pra ChatGPT, Perplexity e Gemini sobre 165 empresas reais de Londres, e conferiu cada resposta contra registro oficial. O resultado: 93% das empresas tiveram pelo menos um fato inventado ou ausente. Empresas pequenas saíram piores, com 50% recebendo algum dado fabricado contra 32% das grandes, e confusão de nome cinco vezes mais frequente nas pequenas.

Insight 1: por que a IA inventa justamente a sua especialidade

Quando um modelo responde sobre alguém com pouco material disponível na internet, ele preenche a lacuna com algo que tem a forma de um fato: nome de especialidade parecida, endereço plausível, horário típico da categoria. O texto sai fluente porque o modelo aprendeu o formato de uma informação verdadeira. Não aprendeu, no momento da resposta, se aquele conteúdo específico é verdadeiro.
O relatório de 2026 do Índice de IA da Stanford HAI mostra a diferença de contexto: quando o modelo recebe um documento pra resumir, os melhores erram entre 1,8% e 5,4% das vezes. Quando a tarefa exige buscar na própria memória, sem documento de apoio, a taxa de erro em benchmarks difíceis varia entre 22% e 94%. Perguntar quem é o profissional tal, no bairro tal, é exatamente esse segundo tipo de pergunta. Não existe nota fiscal, nem registro de conselho, nem página de site sendo lida linha a linha antes da resposta saltar.

Insight 2: duas IAs raramente concordam entre si

Mesmo quando não inventa um fato do zero, a IA tem outro problema. Um estudo da Steady Demand, de agosto de 2026, comparou 1.500 perguntas idênticas sobre negócios locais nos Estados Unidos, feitas pro ChatGPT e pro Gemini. Os dois citaram o mesmo domínio em apenas 8,3% das vezes, e recomendaram a mesma empresa em primeiro lugar em só 4,9% das 783 perguntas em que ambos chegaram a nomear alguém.
Pior: perguntar a mesma coisa duas vezes pro Gemini não garante a mesma resposta. Repetindo 497 consultas idênticas, o conjunto de domínios citados se repetiu em só 43% dos casos, e a empresa recomendada em primeiro lugar se manteve a mesma em apenas 5,1% das vezes. Como controle, o pacote de resultados locais comum do Google, sem IA, manteve o mesmo primeiro lugar em 83,3% das repetições. A instabilidade não é da busca local em geral. É específica de pedir pra um modelo gerar a resposta de novo.

Insight 3: nenhuma tática de otimização mostrou efeito estável

Uma revisão acadêmica de 2026 analisou 45 estudos sobre como aparecer bem em respostas de IA generativa entre 2023 e 2026. A conclusão é desconfortável: nenhuma das táticas populares, como adicionar dados estruturados, citações e estatísticas no texto, mostrou efeito estável, de longo prazo e em várias plataformas ao mesmo tempo. O único ponto que se repetiu entre os estudos foi relevância temática e posicionamento do conteúdo dentro da página, não truque de formatação.
Isso devolve algum controle, mesmo que pequeno. A distinção que ajuda é entre resposta aterrada, a que o modelo monta depois de abrir uma fonte específica no momento da pergunta, e resposta de memória, a que ele monta a partir do que aprendeu no treino, sem abrir nada agora. Manter site, perfil de diretório e bio certos não ensina a IA. Aumenta a chance de uma resposta aterrada encontrar a versão certa em vez de o modelo ter que inventar uma.

Um exemplo real: o erro que bastava trocar de arquivo

Um profissional de área regulada tinha acabado de reformular o site inteiro. Dentro da arte do logotipo, em pixel, estava escrita uma especialidade que não era a dele. Sobreviveu à reforma completa porque ninguém tropeça num erro que não é pesquisável. Bastou achar e trocar o arquivo, numa tarde, depois de encontrado.
A resposta que uma IA generativa dá sobre alguém não tem esse arquivo pra trocar. Não existe painel de edição, não existe solicitar correção que chegue a alguém com autoridade de mudar o que o modelo vai responder na próxima consulta. Corrigir o site resolve pra quem visita o site. Não resolve, na mesma velocidade, o que um modelo já incorporou como padrão sobre aquela categoria inteira.

O que fazer com isso

O artigo 18, inciso III, da LGPD garante ao titular o direito de corrigir dado pessoal incompleto, inexato ou desatualizado, e existe argumento pra tratar uma resposta de IA inventada sobre uma pessoa física identificada como dado pessoal inexato sujeito a correção. O que não existe ainda é um caminho testado de como exercer esse direito: a resposta é gerada no momento, sem base de dados fixa, por uma empresa que pode nem ter CNPJ no Brasil.
Isso não torna o site inútil. Uma pesquisa da BrightLocal mostrou o uso de IA pra achar negócio local subindo de 6% para 45% das pessoas entre um ano e o início de 2026. O site não controla o que a IA inventa quando não sabe, mas é a fonte mais provável de a IA citar certo quando ela de fato busca antes de responder.

O critério prático que sobra: antes de aceitar como fato o que uma IA diz sobre alguém, existe uma fonte que dá pra abrir e conferir, ou aquilo só existe porque soou plausível? Sem fonte clicável, é hipótese, não fato. E vale perguntar de novo, de tempos em tempos, porque a resposta de hoje pode já ser outra na consulta seguinte.

Este artigo é uma versão condensada de uma análise mais aprofundada, com as seis referências citadas, a tabela completa e o glossário, que publiquei em https://chipak.com.br/artigos/o-que-a-ia-responde-sobre-voce-nao-e-editavel

ISO 42001 e ISO 27001: o que se aproveita e o que é trabalho novo

Anderson Chipak — Wed, 28 Oct 2026 20:17:11 +0000

ISO 42001 e ISO 27001: o que se aproveita e o que é trabalho novo

O problema

Quando uma empresa já tem ISO 27001 e começa a avaliar a ISO 42001, a primeira pergunta costuma ser errada: qual das duas é mais importante. A pergunta certa é outra: o que já está pronto e o que precisa ser construído do zero. Sou auditor de sistemas críticos e vejo esse erro de enquadramento travar decisão de orçamento e de prazo com frequência, porque gestor decide pelo nome da norma, não pelo que ela de fato exige.
As duas normas seguem a Estrutura Harmonizada da ISO, a mesma base da ISO 9001: contexto da organização na cláusula 4, liderança na 5, planejamento na 6, apoio na 7, operação na 8, avaliação de desempenho na 9 e melhoria na 10. Essa coincidência não é cosmética. É o mesmo ciclo de planejar, executar, verificar e corrigir, aplicado a dois objetos diferentes.

O que se aproveita

Boa parte do que uma empresa com ISO 27001 já tem rodando serve de base direta para a 42001: política assinada pela direção, auditoria interna obrigatória, análise crítica pela direção e tratamento formal de não conformidade. Até o conceito de parte interessada e a exigência de informação documentada são idênticos nas duas normas.
Na prática, isso tem um efeito concreto na auditoria de certificação. Como as cláusulas 4 a 10 são as mesmas, um organismo de certificação pode conduzir uma auditoria combinada, revisando a estrutura de gestão comum uma única vez e avaliando separadamente apenas o Anexo A de cada norma. O ganho aqui é de tempo e custo de auditoria, não de esforço de implementação. Quem já tem comitê de risco, procedimento de auditoria interna e cultura de documentação não está recomeçando do zero quando decide entrar na governança de IA.

O que é trabalho novo

Dois pontos não se reaproveitam, e são justamente os que custam mais tempo.
O primeiro é a cláusula 6.1.4 da ISO 42001, que exige um processo formal de avaliação do efeito do sistema de IA sobre indivíduos, grupos e sociedade ao longo de todo o ciclo de vida, incluindo o uso previsto e o uso indevido previsível. Não existe cláusula equivalente na 27001, porque a 27001 pergunta o que pode dar errado para a organização, e a 42001 pergunta quem pode ser afetado e como, mesmo que esse alguém nunca tenha escolhido interagir com o sistema.
O segundo é o Anexo A. A ISO 27001:2022 lista 93 controles organizados em quatro temas: organizacional, pessoas, físico e tecnológico. A ISO 42001 lista 38 controles em nove categorias, com foco no ciclo de vida do sistema de IA, na governança de dados usados para treinar e operar o modelo e no uso responsável. Um conjunto trata de segurança da informação em geral. O outro trata do comportamento e do efeito de um sistema que toma ou apoia decisões sobre pessoas.
Documentar esse recorte costuma ser a parte mais lenta do projeto, porque a maior parte das empresas nunca escreveu uma avaliação de impacto nem um inventário de sistema de IA antes de precisar de um.

Um exemplo de como isso aparece na prática

Numa auditoria de mineração sob SOX que conduzi, aprovada pela Ernst & Young sem ressalva, a redução de 90% no tempo de troubleshooting veio da estrutura de governança por trás do controle específico: papéis definidos, evidência rastreável e revisão periódica, antes de qualquer controle individual ser avaliado. A ISO 42001 pede a mesma espinha dorsal, com um recorte diferente, voltado ao sistema de IA em vez de ao ativo de informação.
O erro mais comum que vejo nesse momento é reaproveitar documento sem reaproveitar controle. A tentação é copiar a política de segurança da informação e trocar o título para política de IA. A estrutura do documento pode até se parecer. O conteúdo não pode, porque a 42001 cobre pontos que a 27001 nunca exigiu, como explicabilidade para quem é afetado pela decisão e supervisão humana definida por tipo de decisão. Documento copiado sem esse conteúdo reprova na primeira auditoria interna.

Conclusão

A pergunta de qual norma certificar primeiro depende do risco que já custou caro para a empresa, não de qual norma parece mais relevante em abstrato. Se o histórico é de incidente de dados, a estrutura de informação vem primeiro. Se o histórico é de decisão automatizada questionada por cliente ou regulador, a avaliação de impacto da 42001 resolve o problema mais urgente primeiro, mesmo sem a 27001 ao lado.
Quem já tem a 27001 ganha tempo de auditoria, não ganha o trabalho de inventariar sistemas de IA, montar a avaliação de impacto e selecionar os controles aplicáveis do Anexo A. Isso continua sendo trabalho novo, em qualquer ordem que a empresa escolha.
Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/iso-42001-vs-iso-27001/

LGPD decisão automatizada: o checklist antes do primeiro pedido de revisão

Anderson Chipak — Mon, 26 Oct 2026 20:17:58 +0000

LGPD decisão automatizada: o checklist antes do primeiro pedido de revisão

O problema

Sou auditor de sistemas críticos, e a pergunta que mais ouço de quem responde por risco numa empresa grande é sobre o artigo 20 da LGPD, raramente sobre ISO 42001. Desde 2020, quem é afetado por uma decisão tomada unicamente por tratamento automatizado de dados pessoais pode pedir revisão. Quase nenhuma empresa que eu auditei sabia listar, de cabeça, quais das próprias decisões são unicamente automatizadas hoje e quais ainda têm alguém olhando o caso antes de confirmar.
Scoring de crédito, triagem de currículo, precificação dinâmica e liberação de limite em aplicativo costumam rodar sem esse controle escrito. O titular só descobre que foi decidido por máquina quando o resultado já chegou.

A palavra que decide tudo: unicamente

Se existe uma pessoa entre o modelo e o resultado final, com poder real de mudar esse resultado e usando esse poder de fato, a decisão deixou de ser unicamente automatizada. Se essa pessoa só confirma em lote, sem abrir o caso individual, a decisão continua sendo unicamente automatizada, mesmo com alguém clicando em aprovar no final.
A redação original do artigo 20, aprovada pelo Congresso, previa revisão feita por pessoa natural. A Lei 13.853/2019 retirou essa expressão do caput antes mesmo de a LGPD entrar em vigor, e vetou o parágrafo que previa multa própria para o artigo. O veto não apaga a obrigação. Só retira uma penalidade específica, que passou a seguir a régua geral de sanção da lei, a mesma de qualquer outra infração.
Formalmente, hoje, a lei não exige que o revisor seja humano. A pergunta que decide, na minha leitura, não é se existe humano no processo. É se quem revisa tem poder real de mudar o resultado, e usa esse poder quando o caso individual pede isso. Um aprovador que só roda o mesmo modelo de novo, sem abrir o caso, não cumpre o artigo 20, seja ele humano ou outro sistema.

O que ter pronto antes do pedido chegar

Três frentes resolvem a maior parte do que uma auditoria externa ou a ANPD vai perguntar:

Inventário: lista das decisões que a empresa toma hoje sem nenhuma pessoa olhando o caso individual, atualizada, não um levantamento feito uma vez e esquecido.2. Critério em linguagem simples: o procedimento de cada decisão, escrito para o titular entender sem abrir código-fonte, respeitando segredo comercial onde ele existir de verdade.3. Processo de resposta: quem recebe o pedido, quem tem poder real de mudar o resultado, e em quanto tempo responde. A lei não fixa prazo próprio para essa revisão; o mercado usa como referência os 15 dias corridos que o artigo 19 já exige para outros pedidos do titular. Sem esse inventário, a resposta a um pedido de revisão nasce inventada na hora, sob pressão do prazo, e normalmente erra algum detalhe que o titular, ou a ANPD depois dele, percebe. ## Um cenário comum Uma empresa de crédito ao consumidor usa um modelo de score para aprovar ou negar pedido de empréstimo em segundos. Quando o modelo nega e a pessoa pede revisão, o time de atendimento reabre o mesmo modelo, roda de novo com os mesmos dados de entrada, e devolve a mesma negativa, sem olhar o caso individual. Existe um registro de revisão no sistema. Na prática, é o mesmo algoritmo revisando a si mesmo, e é esse desenho que o artigo 20 não aceita como cumprimento. O custo de ignorar isso está na mesma lei: o artigo 52 prevê multa simples de até 2% do faturamento do grupo no Brasil no último exercício, sem contar tributos, limitada a R$ 50 milhões por infração. O artigo 20 não tem multa própria desde o veto de 2019, então uma falha nele cai nessa régua geral. ## Por que isso é prioridade agora Em 2025 a ANPD fechou uma tomada de subsídios dedicada ao tema, com 124 contribuições recebidas. ANPD decisão automatizada virou prioridade oficial de fiscalização para o biênio 2026 e 2027, ao lado de proteção de dados de criança e adolescente e tratamento de dados pelo poder público. A autarquia está organizando a fiscalização de um instrumento que já existe desde 2020, com nota técnica publicada e agenda regulatória atualizada. ## Onde a ISO 42001 entra O Anexo A da ISO 42001 pede avaliação de impacto, papel definido para quem decide sobre o sistema de IA e mecanismo de contestação para quem é afetado por ele. O artigo 20 pede, na prática, quase a mesma coisa, só que como direito individual do titular, não como controle de gestão da organização. Quem organiza o inventário de sistemas de IA pensando na ISO 42001 resolve boa parte da base documental que o artigo 20 exige. Quem organiza pensando no artigo 20 primeiro chega à ISO 42001 depois com metade do caminho andado. ## Conclusão A decisão que vale tomar esta semana não é certificar a ISO 42001 nem esperar o PL 2338 virar lei. É pegar as três decisões automatizadas que mais afetam gente de fora da empresa hoje, crédito, recrutamento, preço, acesso, e perguntar, para cada uma, quem tem poder real de mudar o resultado quando alguém reclama. Se a resposta for ninguém, só o próprio modelo, o artigo 20 já está sendo descumprido, com ou sem fiscalização no horizonte. Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/lgpd-decisao-automatizada-artigo-20/

O teste que prova se o seu backup funciona, e quase ninguém faz

Anderson Chipak — Wed, 21 Oct 2026 12:01:25 +0000

O teste que prova se o seu backup funciona, e quase ninguém faz

Um painel de hospedagem mostrando "backup concluído às 3h da manhã" está te informando uma coisa só: o pedido de cópia foi aceito e não encontrou erro durante a gravação. Isso é bem diferente de garantir que o arquivo gravado abre, que ele contém o que deveria conter, e que o processo de trazê-lo de volta para o ar funciona do início ao fim.
A maioria das interfaces de backup foi construída para avisar sobre falha de gravação, não sobre falha de restauração. Testar se o arquivo volta exige um passo extra, que consome tempo e espaço, e que nenhuma configuração padrão faz sozinha. Alguém precisa decidir fazer esse teste, de propósito, fora do fluxo automático.

Três pesquisas, três públicos, a mesma falha

Uma pesquisa de 2026 com 319 administradores, desenvolvedores e donos de sites em WordPress, feita pela Melapress, achou que apenas 27,9% deles tinham algum plano de recuperação depois de um incidente de segurança. Não é a minoria técnica que falha nisso. É a maioria, incluindo gente que mexe no próprio site todos os dias.
Sobe um nível na cadeia e o quadro não melhora como seria de esperar. Uma pesquisa de 2024 com 1.000 arquitetos de nuvem e executivos de tecnologia sênior, feita pela Cockroach Labs, achou que menos de um terço dessas empresas, com equipe técnica dedicada e orçamento de infraestrutura, testa failover regularmente, o nome técnico para simular uma pane e verificar se o plano de recuperação funciona de verdade.
No topo da cadeia, onde o incidente já aconteceu e o backup devia estar sendo usado de verdade, a Sophos mediu em 2025, numa pesquisa com 3.400 líderes de tecnologia e segurança em 17 países atingidos por ransomware no ano anterior, que só 54% conseguiram restaurar os próprios dados a partir de backup. A taxa mais baixa dos últimos seis anos medidos pela mesma pesquisa.
Três números, três públicos diferentes, a mesma forma de falha: quem tem equipe, orçamento e motivo forte para testar continua, na maioria, não testando.

Por que a tela confunde, e não por acidente

Um painel que mostra uma lista de datas cria a impressão de profundidade, de que existe um histórico inteiro guardado, pronto para qualquer momento que você precisar. Na prática, a maioria dos planos de hospedagem guarda uma janela limitada, geralmente entre sete e trinta dias, e depois desse prazo a cópia mais antiga é apagada para abrir espaço para a nova, sem nenhum aviso de que isso está acontecendo.
Isso explica por que o problema raramente aparece logo de cara. Nos primeiros meses depois de configurar um backup automático, qualquer teste improvisado tende a funcionar, porque a cópia é recente. O risco cresce com o tempo, exatamente quando a confiança também cresce, porque ninguém voltou a testar desde a primeira vez.

O que a cópia de segurança não resolve sozinha

Vale separar um risco do outro, porque os dois se parecem na superfície e são resolvidos de formas diferentes. Ter uma cópia de segurança protege contra perda de conteúdo, apagão de arquivo, erro de atualização que quebra o site inteiro. Não protege contra um problema de coordenação, que é o que acontece quando mais de uma pessoa mexe no mesmo site sem um processo que avise quem fez o quê.
Duas pessoas mexendo no mesmo site, cada uma com a própria cópia de trabalho guardada no próprio computador, é o cenário em que uma versão nova da página inicial é publicada em cima de outra que tinha ido ao ar na noite anterior. O que salva, nesses casos, costuma ser a outra versão ainda existir, por sorte, no disco de quem a fez, não um processo pensado para essa situação.
A régua prática para quem atua sozinho é mais simples do que parece: mesmo sem segunda pessoa, qualquer mudança que você fizer de um fornecedor para outro, ou numa reformulação grande, merece uma cópia datada do estado anterior, separada do processo automático do hospedeiro.

A objeção mais comum

"Meu plano de hospedagem já inclui backup automático. Por que eu preciso me preocupar com isso?"
Porque o plano garante que o processo de cópia roda, não que ele resolve o seu problema específico no dia em que você precisar dele. O backup incluso costuma ficar hospedado no mesmo provedor que hospeda o site, dentro da mesma janela de retenção curta, e sob os mesmos termos de uso de um serviço que você não controla. Se o problema que te atingiu for justamente esse provedor, uma conta suspensa, uma falha do próprio sistema de backup, uma mudança de política sem aviso, a cópia incluída sofre o mesmo risco que você estava tentando evitar.
Essa lacuna não é privilégio de quem administra site grande. Uma pesquisa de 2016 encomendada pela Nationwide, com 502 pequenos empresários americanos à frente de negócios de até 300 funcionários, achou que 68% deles não tinham nenhum plano de recuperação escrito, apesar de quase a metade reconhecer que levaria pelo menos três meses para se recuperar de um desastre sem esse plano.

O teste não precisa ser semanal

Testar uma restauração custa tempo, e vale dizer isso em voz alta em vez de empurrar o custo para debaixo do tapete. O trade-off real não é "testar ou não testar". É decidir com que frequência o seu site muda o suficiente para justificar um novo teste. Um site que não muda há meses pode viver com um teste por ano. Um site em reformulação ativa, com fornecedor novo entrando, merece teste antes de cada mudança estrutural grande.
Precisa ser feito pelo menos uma vez, para você saber como é o processo e quanto tempo ele leva, e de novo antes de qualquer mudança grande no site. O resto do tempo, a cópia existe em segundo plano, e você vive com um risco conhecido em vez de um risco que só aparece no pior momento.

A pergunta que resolve isso não pede uma rotina nova toda semana. Pede uma pergunta específica, feita antes da próxima vez que alguém for tocar em algo estrutural: se você precisasse voltar para o estado de ontem agora mesmo, você sabe que consegue, ou só acha que consegue?

This article is a condensed version of a deeper analysis I published at https://chipak.com.br/artigos/ter-backup-do-site-nao-e-o-mesmo-que-conseguir-restaurar

A due diligence de fornecedor de IA que o questionário de segurança não cobre

Anderson Chipak — Tue, 20 Oct 2026 20:14:02 +0000

A due diligence de fornecedor de IA que o questionário de segurança não cobre

O problema

Todo contrato de software passa por um questionário de segurança da informação: certificação, política de senha, criptografia em trânsito e em repouso. Sou auditor de sistemas críticos e vejo o mesmo questionário ser aplicado, sem nenhum ajuste, a fornecedor de IA. Nenhum campo pergunta de onde veio o dado que treinou o modelo, se o fornecedor reaproveita a base do cliente para melhorar o produto de outro, ou se existe alguém capaz de explicar por que o sistema recusou um crédito específico.
Segurança da informação protege o dado parado. Due diligence de fornecedor de IA protege a decisão que o modelo toma com esse dado. São duas auditorias diferentes, e a segunda raramente existe num processo de compra tradicional.

Seis frentes, não uma

A pergunta certa para um fornecedor de IA cobre seis frentes, e faltando uma delas o contrato protege a empresa de metade do risco que ela corre de verdade:

Dado de treinamento: de onde vem, teve consentimento do titular, pode ser reaproveitado para treinar o modelo de outro cliente.2. Explicabilidade: existe um responsável técnico capaz de explicar uma decisão específica do modelo, não só a média geral de acerto.3. Direito de auditoria: o contrato permite pedir evidência técnica quando necessário, não só um relatório anual padronizado.4. Notificação de incidente: prazo e canal definidos em contrato, não deixados para a boa vontade do fornecedor.5. Portabilidade: o dado e o modelo treinado com ele saem com a empresa se o contrato terminar.6. Subcontratação: o fornecedor usa modelo de outro provedor por trás do produto, e que responsabilidade assume por isso. Cada linha dessa lista precisa virar cláusula, não item de planilha de compra. É aí que a due diligence para de ser teoria. Vale também para o que já está contratado. Um ERP ou um CRM que ganhou um recurso de IA numa atualização recente é, para efeito de risco, um fornecedor de IA novo, mesmo que o contrato original seja antigo. Normalmente ninguém revisita esse contrato quando o recurso chega embutido, e o ponto cego some do radar de compras porque nenhum contrato novo foi assinado para ele. ## A cláusula de auditoria, em três partes Uma cláusula de auditoria que funciona tem três partes. Primeiro, o direito de solicitar evidência técnica específica, não um relatório de conformidade genérico que o fornecedor manda para qualquer cliente. Segundo, o prazo para responder a esse pedido, porque direito de auditoria sem prazo vira pedido que fica três meses sem resposta. Terceiro, o que acontece se o fornecedor se recusar: multa, direito de rescisão, ou os dois. Fornecedor que recusa assinar essa cláusula já deu uma resposta sobre o risco antes de qualquer demonstração do produto. Fornecedor pequeno às vezes recusa porque nunca formalizou o próprio processo interno, e isso já é um dado. Fornecedor grande que recusa por política comercial costuma aceitar uma versão mais restrita, limitada a evidência documental em vez de acesso a sistema. O que não vale assinar é um contrato de IA sem nenhuma cláusula de auditoria, substituída só por uma declaração de boas práticas no site do fornecedor. ## Terceirizar o processamento não terceiriza a responsabilidade A LGPD trata o fornecedor de IA como operador: ele trata o dado segundo a instrução do controlador, que fiscaliza se essa instrução e a lei estão sendo seguidas. Controlador e operador respondem de forma solidária por dano causado em violação à legislação de proteção de dados. Na prática, isso significa que a empresa que contrata continua exposta se o fornecedor errar, e o contrato é o único lugar onde essa exposição pode ser dividida de forma explícita, com ressarcimento e prazo definidos, em vez de discutida depois do incidente. ## Um cenário comum Uma empresa de porte médio contrata um fornecedor de IA para triagem de currículo e assina o contrato padrão do próprio fornecedor, sem alteração nenhuma. Seis meses depois, um candidato questiona a decisão automatizada, e o jurídico pede ao fornecedor a explicação do modelo que recusou a candidatura. A resposta demora três semanas e vem incompleta, porque o contrato nunca obrigou prazo nem formato de resposta. A due diligence existiu, mas só em e-mail trocado antes da assinatura. Nunca virou cláusula, e por isso não valeu nada no momento em que precisou valer. Numa auditoria de SOX em mineração que conduzi, a aprovação da Ernst & Young veio sem ressalva porque cada controle tinha evidência rastreável por trás, não promessa verbal de quem operava o sistema. Due diligence de fornecedor de IA pede o mesmo padrão: evidência que sobrevive a uma pergunta de auditor externo, não resposta que soa bem numa reunião. ## O erro que custa mais caro Tratar due diligence como etapa única, feita antes da assinatura e arquivada depois, é o erro mais caro dos quatro que vejo se repetir. Fornecedor de IA muda de modelo, troca de subcontratado e atualiza a política de uso de dado com frequência maior que qualquer contrato de software tradicional, e nada disso aparece automaticamente para quem contratou. Contrato bom no dia da assinatura e nunca mais revisitado vale tanto quanto contrato nenhum, porque o risco de fornecedor de IA muda de nível sem o cliente ser avisado: o modelo é atualizado do lado do fornecedor, e quem contratou só descobre a mudança quando o comportamento do sistema já é outro. ## Conclusão O custo de pular qualquer uma dessas frentes raramente aparece no mês da assinatura. Aparece meses depois, quando um incidente expõe que ninguém sabia explicar por que o modelo decidiu o que decidiu, e a primeira pergunta de quem investiga é sempre a mesma: o contrato previa isso, ou a empresa só confiou na palavra do fornecedor? Antes de assinar o próximo contrato de fornecedor de IA, pergunte quem, na sua empresa, vai cobrar essa cláusula de auditoria no dia em que o modelo errar. Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/due-diligence-fornecedor-ia/

Por que o inventário de sistemas de IA vem antes de qualquer política

Anderson Chipak — Fri, 16 Oct 2026 20:18:01 +0000

Por que o inventário de sistemas de IA vem antes de qualquer política

O problema

Toda empresa que decide escrever uma política de uso de IA parte do que já conhece: o ChatGPT que todo mundo usa, talvez o Copilot, talvez uma ferramenta de atendimento. O problema é que essa lista nasce da memória de quem está na sala, não de um levantamento. Sou auditor de sistemas críticos e vejo esse atalho se repetir: a política sai bonita, cobre o óbvio e ignora o modelo de score que roda dentro do sistema de crédito há anos, ou o módulo de triagem de currículo que já vem embutido na ferramenta de recrutamento.
Inventário de sistemas de IA é a lista do que a equipe usa de fato, com dono, propósito, dado e fornecedor registrados por sistema. É o requisito prático da ISO 42001 e da estrutura de risco do NIST. Sem ele, avaliação de risco, política de uso e auditoria interna de IA não têm onde se apoiar.

Quem é o dono disso

Na maioria das empresas, a resposta no primeiro dia é ninguém. TI sabe o que foi comprado com orçamento de TI. Compliance sabe o que passou por contrato. Nenhuma das duas vê o que o marketing instalou como extensão de navegador, nem o que o RH liga dentro da ferramenta de recrutamento.
O inventário precisa de uma pessoa nomeada, não de um comitê inteiro supervisionando de longe. Alguém que receba a pergunta "esse sistema está na lista?" e saiba responder sem convocar reunião. Sem esse dono, o inventário vira documento atualizado uma vez, no mês em que o projeto começou, e esquecido depois.

Os quatro passos, e o shadow AI que eles revelam

Montar esse inventário não é projeto de TI com orçamento próprio. É levantamento, e cabe numa planilha:

Liste o que foi contratado: contrato, nota fiscal, licença com módulo de IA declarado.2. Pergunte pra cada área o que ela usa de fato: qual ferramenta, para qual tarefa, com que frequência, conta da empresa ou pessoal.3. Olhe dentro dos sistemas que a empresa já tem: ERP, CRM, ferramenta de recrutamento. A IA embutida em produto comprado por outro motivo é a que mais escapa de um levantamento feito só por e-mail.4. Registre em campos fixos: sistema, dono, propósito, dados, fornecedor, risco. Parágrafo descritivo não sobrevive a uma auditoria. O segundo e o terceiro passo são os que custam caro pular. Num cenário comum desse tipo de levantamento, a lista oficial traz seis sistemas, todos com contrato assinado. Ao perguntar pra cada área o que ela usa de fato, sem ameaça de punição, aparecem mais nove: corretor de currículo dentro da ferramenta de recrutamento, resumo automático de reunião que alguém assinou sozinho, extensões de navegador usadas pra rascunhar proposta, um complemento de planilha já fazendo previsão de venda. A lista real termina mais que o dobro da lista oficial. Esse uso não declarado tem nome, shadow AI, e ele não desaparece porque a empresa não perguntou sobre ele. ## O que isso tem a ver com LGPD Boa parte dos sistemas levantados processa dado pessoal: currículo, histórico de crédito, prontuário. A LGPD já exige que controlador e operador mantenham registro das operações de tratamento de dados pessoais que realizam. Quem já mantém esse registro tem metade dos campos do inventário de IA prontos: dado que entra e dado que sai são colunas que os dois documentos compartilham. Os dois não são o mesmo documento, o registro de tratamento documenta operação sobre dado pessoal e o inventário de IA documenta sistema e modelo, incluindo os que não tocam em dado pessoal nenhum, mas onde eles se cruzam vale linkar um ao outro em vez de duplicar o levantamento. ## Três erros comuns nesse levantamento O primeiro é confundir inventário de IA com inventário de software. Uma licença de ferramenta de produtividade com um botão de "resumir com IA" entra na lista de ativos de TI há anos; só vira item do inventário de IA quando alguém registra o que aquele botão decide ou recomenda, com que dado e para quem. O segundo é tratar o levantamento como auditoria pontual, feita uma vez pra satisfazer um questionário de cliente ou uma certificação, e arquivada depois. Um sistema que troca de fornecedor de modelo no meio do contrato, ou que passa a processar um dado novo depois de uma atualização, muda de risco sem avisar ninguém, e o inventário parado não capta essa mudança. O terceiro é concentrar o levantamento só em sistema voltado pra fora, o chatbot de atendimento, a recomendação visível ao cliente, e esquecer o que roda por dentro: triagem de currículo, priorização de chamado, detecção de fraude. Esses sistemas internos tomam decisão sobre pessoa com a mesma força que um sistema voltado pro cliente final, e costumam ser os que menos têm dono claro. ## O custo de pular essa etapa Ele não aparece no dia em que a política é publicada. Aparece meses depois, quando um cliente grande manda um questionário de due diligence perguntando quantos sistemas de IA a empresa opera, com que dado e sob qual risco, e a resposta precisa ser montada às pressas, sistema por sistema, porque nunca existiu de forma consolidada. Eu vejo o mesmo atraso em auditoria de sistema crítico fora do contexto de IA: quem audita primeiro pergunta o que existe, não o que está documentado em política. Um sistema sem dono nem registro é, para efeito de auditoria, um sistema que a empresa não controla, mesmo funcionando bem no dia a dia. ## Conclusão Avaliação de impacto, política de uso e auditoria interna de IA dependem de uma lista que já exista antes delas. Tentar qualquer uma das três sem esse inventário é desenhar controle para um sistema que ninguém provou que existe. Antes de aprovar qualquer política de uso de IA generativa, pergunte quem é o dono do inventário da sua empresa hoje. Se a resposta demorar mais que cinco segundos, já apareceu o primeiro ponto a resolver. Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/inventario-sistemas-ia/