DEV Community: Anderson Chipak

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/

O que o psicólogo pode (e não pode) publicar sobre o próprio trabalho

Anderson Chipak — Fri, 16 Oct 2026 11:08:24 +0000

O que o psicólogo pode (e não pode) publicar sobre o próprio trabalho

O elogio que não pode ir ao ar

Um paciente manda uma mensagem depois de uma sessão difícil. "Você mudou a minha vida." Está escrito por conta própria, com nome, pronto para uma peça do Instagram.
Essa peça não pode ser publicada. Não porque falte qualidade, nem porque o elogio pareça falso. O Conselho Federal de Psicologia trata depoimento de paciente como risco mesmo quando é verdadeiro, mesmo quando a pessoa autorizaria por escrito se fosse perguntada.
A regra não nasceu em 2022. Vem se somando desde 2005, numa sequência de normas em que nenhuma revogou a anterior: o Código de Ética de 2005, a consolidação de 2007, o direito ao nome social em 2018 e a nota técnica de 2022 que estendeu tudo isso às redes sociais. Uma peça publicada hoje responde pelas cinco ao mesmo tempo.

O que pode ser divulgado, e como

Formação, público atendido, abordagem teórica e metodologia de trabalho podem aparecer, desde que toda peça traga nome completo (ou nome social), a palavra "psicólogo" e o número do CRP. Isso vale para site, perfil de rede social, cartão e qualquer outro formato, sem exceção.
A regra é avaliada peça a peça, não pelo perfil inteiro. Uma clínica com vários psicólogos e um único Instagram erra exatamente aqui: a bio identifica a marca, mas cada post que fala do trabalho de uma psicóloga específica precisa trazer o nome e o CRP dela, não só uma vez em algum lugar do perfil.

As sete vedações do artigo 56

O Código de Ética lista, desde 2007, o que nenhuma peça pode conter: previsão de resultado, técnica sem comprovação científica, atividade fora da função do psicólogo, honorário usado como concorrência desleal, autopromoção em detrimento de colega, invasão de outra área profissional e conteúdo falso ou sensacionalista.
Quase todo conteúdo popular sobre "o que psicólogo pode postar" fala só de depoimento e de preço. As outras quatro vedações raramente aparecem, e são justamente as que mais faltam nas listas de marketing escritas por quem nunca abriu a resolução.

Por que nem o consentimento resolve

Aqui está o ponto que mais surpreende quem só leu um resumo da norma. Mesmo com consentimento expresso e por escrito, a orientação de 2022 é não usar depoimento nem foto de paciente. Ela não proíbe de forma terminante. Desaconselha, porque o risco de exposição continua existindo depois que a pessoa autorizou, sobretudo quando se trata de criança ou adolescente.
Um paciente que autoriza por escrito não torna a publicação recomendada. A nota técnica separa "permitido" de "recomendado": tecnicamente permitido, mas desaconselhado pelo risco de exposição da pessoa atendida. E a representação ética não depende de o paciente se incomodar depois. Qualquer um pode representar contra a peça, inclusive um terceiro que nunca teve relação com aquele atendimento.
O médico, pela mesma situação, segue outra régua. A resolução do CFM de 2023 passou a permitir elogio espontâneo e sóbrio, sem promessa. Dois conselhos de saúde, o mesmo tipo de conteúdo, calibração de risco oposta. Copiar a norma de uma profissão regulada para outra vizinha, mesmo as duas em área de saúde, é o erro mais fácil de cometer.

Preço como propaganda, não como informação

A nota técnica de 2022 veda termos como "preço social", "desconto", "pacote promocional", cupom e sorteio. Convênio com instituição e trabalho voluntário continuam liberados, desde que o voluntariado não seja usado como isca de captação.
A linha não está em mencionar valor, está no enquadramento. Uma peça que informa, de forma neutra, quanto custa a sessão não vira irregular só por citar número. O que muda de categoria é apresentar o preço como vantagem comercial, comparado com o de outro profissional ou amarrado a prazo de validade.

Quem responde quando a peça nasce em outro lugar

Terceirizar a redação não terceiriza a responsabilidade. Mesmo quando a divulgação é feita com apoio de agência, plataforma ou ferramenta de inteligência artificial, continua sendo dever do psicólogo verificar se o conteúdo cumpre a norma antes de publicar. Ele responde pela peça mesmo sem ter escrito uma linha dela.
Isso já apareceu, fora da psicologia, de um jeito concreto. Um texto explicando oito condições clínicas foi escrito para o site de uma profissional de área regulada, em tom informativo, sem promessa de resultado, com aviso de que não substituía consulta. Mesmo assim, foi entregue marcado como pendente de revisão e aprovação dela, antes de qualquer publicação, porque era conteúdo técnico de uma profissão com conselho. Quem assina o registro responde por ele, não quem redigiu o rascunho.

O que sobra, na prática

Depois de tirar depoimento, preço como propaganda, previsão de resultado e autopromoção, ainda sobra bastante espaço. Formação, abordagem, metodologia, público atendido e conteúdo educativo sobre a ciência psicológica seguem liberados, e são, na prática, o que sustenta a maior parte de um perfil profissional sério.

O que muda o centro de gravidade de uma peça é o fechamento. "Ansiedade tem tratamento, e a abordagem que eu uso trabalha o pensamento automático por trás da crise" informa. A mesma frase, fechada com uma chamada direta para marcar sessão, muda de categoria e entra na régua inteira da publicidade.

This article is a condensed version of a deeper analysis I published at https://chipak.com.br/artigos/o-psicologo-nao-pode-publicar-nem-o-elogio-do-paciente

Gap analysis ISO 42001: por que o total de itens pendentes engana

Anderson Chipak — Wed, 14 Oct 2026 20:14:30 +0000

Gap analysis ISO 42001: por que o total de itens pendentes engana

O problema

Todo relatório de gap analysis ISO 42001 chega com uma lista de itens marcados como pendentes. O primeiro instinto de quem recebe esse relatório é somar quantos itens vieram assim e tirar uma conclusão de tamanho do projeto. Esse instinto erra quase sempre, porque nem todo item pendente custa o mesmo, e um relatório que não separa esses pesos vira ruído em vez de plano de ação.
Sou auditor de sistemas críticos, e vejo esse erro se repetir em empresas de porte bem diferente: gestor recebe o gap analysis, vê metade dos controles do Anexo A fora de conformidade e decide, na mesma reunião, que o projeto é grande demais, ou que é pequeno demais para preocupar o conselho. Os dois extremos vêm do mesmo vício de leitura.

Os quatro níveis que importam mais que o total

Um relatório de gap analysis ISO 42001 bem feito não entrega nota única nem percentual isolado. Ele classifica cada requisito da norma e cada controle do Anexo A selecionado em quatro níveis: conforme, quando existe evidência documentada e recente; parcialmente conforme, quando o processo existe mas é aplicado de forma inconsistente ou sem registro completo; não conforme, quando não há processo, registro nem dono definido; e não aplicável, quando o controle foi excluído com justificativa escrita no documento de aplicabilidade.
Essa classificação em quatro níveis existe porque uma marcação simples de sim ou não esconde a diferença entre uma lacuna de fundação e um ajuste de detalhe. Prefiro tratar cada não conformidade como um registro com três campos obrigatórios: o que falta, por que falta e quem vai resolver, em vez de uma linha solta numa planilha de cem itens.

"Não aplicável" não é "não conforme"

Confundir essas duas categorias é o erro de classificação mais caro que vejo. "Não aplicável" é uma decisão documentada de que aquele controle não se encaixa no escopo da empresa, por exemplo, controle de fornecedor de modelo de fundação numa empresa que só usa modelos prontos sem retreinar nada. "Não conforme" é lacuna real, sem justificativa, e conta contra a empresa na hora de fechar o plano de ação. Um relatório que mistura as duas categorias infla artificialmente o tamanho do projeto, porque trata como pendência real algo que já deveria estar fechado com uma linha de justificativa.

Por que o total de pendentes engana

O erro mais comum que vejo é tratar a contagem de itens pendentes como medida de esforço. Um controle sem dono definido pode ser resolvido numa reunião de uma hora. Um processo de avaliação de impacto inexistente para todos os sistemas de IA em produção pode consumir meses de trabalho. A leitura certa separa lacuna fundacional, que trava qualquer avanço seguinte, de lacuna de melhoria, que pode esperar o próximo ciclo sem risco nenhum.
Uso a lógica de quatro funções do NIST, mapear, medir, gerenciar e governar, para priorizar um relatório de gap analysis: primeiro resolva o que impede mapear os sistemas de IA em uso, depois o que impede medir o risco de cada um, só então ataque o que melhora a governança já existente.

Um exemplo de reclassificação

Uma empresa recebe o relatório e vê a maior parte dos controles do Anexo A marcados fora de conformidade. O primeiro instinto é declarar o projeto grande demais. Ao reclassificar item por item, boa parte desses itens eram controles de fornecedor de modelo de fundação, marcados como não conforme quando deveriam estar como não aplicável, porque a empresa só usa modelos prontos de terceiros sem retreinamento. A lacuna real, depois da reclassificação, ficou bem menor, concentrada em três processos: inventário de sistemas de IA, avaliação de impacto e papéis de governança.
Essa reclassificação é o primeiro trabalho depois de receber o relatório, antes de qualquer plano de ação ou orçamento. Boa parte do que aparece como não aplicável só se sustenta se a empresa documentar por que aquele controle específico não se encaixa no escopo dela, com critério consistente para os dois lados do relatório.

O que fazer com cada não conformidade

Para cada item não conforme, recomendo registrar três coisas antes de corrigir: o motivo da lacuna, se o processo nunca existiu, existiu e foi abandonado, ou existe mas em outra área sem integração, o dono responsável por fechar e uma data realista. Uma avaliação de impacto de um sistema de IA de porte médio costuma levar entre 80 e 120 horas de trabalho qualificado. Essa é uma premissa minha, baseada no volume de documentação que normalmente falta, não um fato medido para qualquer empresa específica.

O gap analysis não é a certificação

Um relatório de gap analysis mostra onde a empresa está hoje. Ele não substitui a auditoria interna, a análise crítica pela direção nem a evidência acumulada ao longo de meses de operação, etapas que a própria norma exige antes de qualquer organismo de certificação emitir o certificado. Tratar o gap analysis como linha de chegada é um dos erros mais caros que vejo nesse processo. A auditoria interna confirma, meses depois, se o que foi corrigido continua valendo, e pular essa etapa para correr direto à certificação é um dos jeitos mais comuns de reprovar numa auditoria externa.

Conclusão

Um relatório com muita não conformidade não significa, sozinho, que a certificação está longe. Três não conformidades fundacionais, sem inventário, sem avaliação de risco e sem dono de processo, pesam mais do que vinte itens de melhoria pontual. O relatório já diz onde cavar. A pergunta que resta é em que ordem, e essa ordem muda o tamanho do projeto muito mais do que o percentual que aparece na primeira página.
Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/gap-analysis-iso-42001-resultado/

O teste que decide se uma automação de atendimento está pronta para um caso real

Anderson Chipak — Wed, 14 Oct 2026 11:05:32 +0000

O teste que decide se uma automação de atendimento está pronta para um caso real

A condição que nunca foi verdadeira

Um atendente automático de mensagens tinha uma tarefa simples: reconhecer de qual anúncio a pessoa tinha vindo e citar o assunto já na saudação. Testei uma vez, funcionou, segui para o próximo cliente.
A condição que checava isso nunca foi verdadeira. Nenhuma vez. Todo contato que chegava de anúncio recebeu a mesma saudação genérica, desde o primeiro dia, e nenhum erro apareceu em lugar nenhum. O painel mostrava mensagens entregues, zero falha registrada. A automação simplesmente fazia menos do que prometia, em silêncio, até alguém ler o histórico inteiro e notar o padrão.
Funcionalidade que falha em silêncio parece funcionar para sempre. O que não quebra, ninguém volta a olhar.

A régua que separa o que pode automatizar do que não pode

Em qualquer atendimento que mistura agendamento com dúvida de quem está do outro lado, existe uma linha que vale a pena desenhar antes de ligar qualquer automação.
De um lado fica o que é regra fixa: marcar horário, confirmar presença, lembrar da consulta, repetir endereço e forma de pagamento. O resultado certo já existe antes da pergunta chegar, é só comparar uma data contra uma agenda ou repetir uma informação que não muda de pessoa para pessoa. Isso pode sair da sua mesa com segurança, porque o julgamento já foi feito uma vez, no momento de escrever a regra.
Do outro lado fica tudo que exige julgar o caso na hora: responder dúvida sobre sintoma, decidir o tom de uma resposta a alguém ansioso, confirmar se um horário específico serve para um caso específico. Aqui o risco de errar não é atrasar uma resposta, é entregar algo errado com aparência de certeza, e isso pesa mais quando o dado em jogo é sensível.
Uma revisão publicada em 2022 na npj Digital Medicine avaliou dez estudos sobre ferramentas digitais de triagem de sintoma, e encontrou acurácia diagnóstica entre 19% e 37,9%. Até a parte mais objetiva dessas ferramentas, decidir se o caso espera ou corre, varia tanto de ferramenta para ferramenta que chega a errar em quase metade dos casos nas piores delas.

Por que uma execução certa não prova nada

Um teste separado, numa automação de cadastro e renovação de cliente, rodou oito registros idênticos em sequência. O primeiro terminou sem erro. Os sete seguintes falharam todos pelo mesmo motivo, uma condição que dependia do estado deixado pela execução anterior e que ninguém tinha previsto. De oito tentativas iguais, só uma em oito saiu certa.
O critério de "pronto" que valia até esse teste era simples: rodar uma vez e ver se funciona. Funcionou, uma vez. O problema só apareceu na repetição. A correção não foi apenas no código, foi no critério: "pronto" passou a exigir repetir a mesma ação várias vezes seguidas, em sequência, antes de confiar numa situação real.
A mesma lógica vale para um lembrete de consulta. Funcionar na primeira vez não prova que vai funcionar na vigésima, na que cai em feriado, na que a pessoa reagenda duas vezes. Prova só que funcionou naquela vez específica, com aquele conjunto específico de condições.

Como testar sem usar uma pessoa real como primeira tentativa

Dois critérios resolvem a maior parte do risco de um teste que vaza para fora do ambiente de teste.
O primeiro: qualquer teste que possa, por engano, chegar a um contato real usa um nome obviamente falso. Um aviso no meio da mensagem não protege ninguém, porque às vezes o que aparece numa tela de celular é só o nome, sem o resto do texto. "Maria da Silva" não desperta suspeita. Um nome que claramente não existe se denuncia antes de causar dano.
O segundo, mais caro quando falha: o número ou endereço de quem vai receber a mensagem se confere antes de transmitir qualquer dado, nunca depois. Um dígito errado no número de WhatsApp manda a confirmação de uma consulta, ou o resultado de um exame, para um estranho.
Quando o dado envolvido é de saúde, o risco muda de categoria. A Lei Geral de Proteção de Dados trata "dado referente à saúde" como dado pessoal sensível, no mesmo grupo de origem racial e convicção religiosa, e exige medidas técnicas e administrativas capazes de evitar que esse tipo de informação chegue a quem não devia.

O limite que continua sendo seu depois que a automação funciona

Depois que a parte fácil está automatizada e testada, existe uma tentação de deixar a mesma ferramenta responder também a mensagem mais longa, a dúvida mais específica. Tecnicamente costuma ser simples de configurar. A razão para recusar não é técnica.
Quem responde pelo atendimento continua sendo quem tem a formação para isso, não uma ferramenta configurada para parecer que entende o caso. O máximo que uma automação deveria fazer, nesse território, é preparar um rascunho para revisão, nunca enviar sozinha algo que carrega o peso de um julgamento profissional.
Isso também não termina no dia em que a automação entra no ar. Preço reajustado, horário alterado, um serviço que parou de existir: cada mudança que não chega até a automação se transforma numa resposta errada, repetida até alguém perceber. O problema nunca é a automação ter sido mal configurada. É ninguém ter sido designado para atualizá-la depois.

Quem atende sozinho sente esse gargalo direto: a atualização depende de lembrar, e é a mesma cabeça que decide todo o resto. Quem divide a operação com sócio ou secretária troca esse risco por outro, o de duas pessoas editando a mesma mensagem automática em direções diferentes, sem avisar uma à outra, até alguém de fora receber uma informação de um canal e outra de outro. Nos dois casos a solução não é mais ferramenta. É decidir, antes de qualquer mudança de preço ou horário entrar no ar, quem tem a palavra final sobre o texto que a automação envia.

Este artigo é uma versão condensada de uma análise mais profunda que publiquei em https://chipak.com.br/artigos/o-que-automatizar-no-atendimento-e-o-que-fica-com-voce

ISO 42001 não é lei em país nenhum, mas o cliente já cobra como se fosse

Anderson Chipak — Mon, 12 Oct 2026 17:10:51 +0000

ISO 42001 não é lei em país nenhum, mas o cliente já cobra como se fosse

O problema

Nenhum país tornou a ISO/IEC 42001 obrigatória por lei. Não o Brasil, não a União Europeia. E ainda assim a pergunta "isso é obrigatório?" aparece cada vez mais em reunião de diretoria. Eu audito sistemas críticos sob SOX, ITIL e LGPD há quase vinte anos, e vejo o mesmo padrão se repetir com toda norma nova: ela é voluntária no papel, e quem cobra na prática não é o legislador.
São três fontes de pressão diferentes, e misturá-las leva a duas decisões ruins: ignorar o assunto porque "não é lei ainda", ou certificar às pressas achando que isso resolve uma obrigação legal que nem existe.

O que já é obrigatório, com ou sem ISO 42001

A LGPD trata de decisão automatizada desde que entrou em vigor, no artigo 20. Qualquer sistema que decida crédito, contratação ou preço sem revisão efetiva cai nesse guarda-chuva, com ISO ou sem. A redação aprovada pelo Congresso previa revisão humana explícita; essa palavra caiu na versão sancionada, mas a exigência de revisão capaz de mudar o resultado continua valendo. Essa obrigação roda desde 2020, sem esperar nenhuma lei de IA nova.
Fora da LGPD, o cenário mais comum que encontro é ISO 42001 virando cláusula de contrato: due diligence, licitação ou renovação pedindo evidência de gestão de dados e de modelos de IA. Auditoria externa, Big Four ou não, pergunta por controle de acesso, log e rastreabilidade de decisão, com IA ou sem.

O que a certificação cobre, e o que não cobre

Aqui está o ponto que mais gente erra, inclusive consultoria vendendo a certificação como escudo jurídico. O EU AI Act prevê, no Artigo 40, que sistemas de alto risco em conformidade com normas harmonizadas publicadas no Jornal Oficial da União Europeia são presumidos conformes com o regulamento. A presunção não nasce da qualidade técnica da norma; nasce de um procedimento formal de citação que a Comissão Europeia controla.
A ISO/IEC 42001 não passou por esse procedimento e não está citada no Jornal Oficial. A norma desenhada especificamente para o Artigo 17 do AI Act é a EN 18286, não a ISO 42001. São objetos diferentes: a ISO 42001 certifica um sistema de gestão organizacional; o AI Act regula cada sistema de IA de alto risco individualmente, como produto.
Isso não torna a certificação inútil. Boa parte do trabalho de preparação é o mesmo: política, inventário, avaliação de risco, auditoria interna. Só que, juridicamente, a presunção de conformidade com o AI Act não existe enquanto nenhuma norma harmonizada estiver publicada.
E o PL 2338 brasileiro? O Senado aprovou o texto em dezembro de 2024 e o enviou para a Câmara. Desde então o projeto está parado numa comissão especial esperando parecer do relator, com votação empurrada para depois das eleições de outubro de 2026. A Câmara já incorporou mais de trinta propostas apensadas ao texto original, e esse volume de emenda costuma mudar detalhe até o fim. O que dá pra afirmar com segurança é a estrutura geral, regulação baseada em risco, parecida com o desenho europeu, não uma lista fechada de normas obrigatórias.

Um exemplo de fora do mundo de IA

Uma das auditorias que conduzi foi de controles de TI sob SOX numa mineradora, aprovada pela Ernst & Young sem ressalvas. Não foi um caso de ISO 42001, a norma nem existia com esse escopo na época. Mas o mecanismo de pressão é o mesmo que vejo hoje em governança de IA: o auditor externo não pergunta se você tem certificado, pergunta se você tem controle documentado, testável e com dono.

Quando vale certificar mesmo sem lei obrigando

Eu considero a certificação em três situações concretas, não como regra geral: quando o cliente já pede, formal ou informalmente, numa licitação ou contrato B2B; quando a empresa vende produto baseado em IA para o mercado europeu e precisa mostrar maturidade de gestão; quando o conselho ou o jurídico já está nervoso o bastante para pedir alguma evidência formal.
Fora dessas três situações, o caminho mais barato costuma vir primeiro: inventário dos sistemas de IA em uso e uma política curta assinada pela diretoria. Esse caminho falha quando três ou quatro clientes grandes já pedem evidência formal ao mesmo tempo; nesse ponto, organizar a documentação uma vez custa menos que responder cada due diligence manualmente.

Conclusão

A resposta certa pra "é obrigatório" depende de quem está cobrando, não de um sim ou não simples. Cliente, auditor e investidor já cobram, mesmo sem lei nenhuma. O legislador brasileiro ainda não decidiu nada, e o legislador europeu decidiu, mas não do jeito que boa parte da consultoria está vendendo por aí.
Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/iso-42001-e-obrigatoria/