Em 11 de junho de 2026 entrou em vigor no estado de Washington a SB 5395, sancionada em 23 de março. O texto faz uma distinção que quase nenhum desenho de agente de IA em operadora de saúde faz explicitamente: algoritmo pode processar e aprovar um pedido de autorização, mas não pode negar por necessidade médica sem revisão de profissional habilitado.
Vale reler, porque a assimetria é o ponto inteiro. A lei não trata "usar IA" como uma permissão única que se concede ou se nega em bloco. Ela separa aprovar de negar, e coloca a barreira de um lado só.
Isso não é nota de compliance. É especificação de arquitetura escrita em linguagem jurídica, e chega no momento em que o mercado brasileiro está exatamente nessa curva. Ao longo de agosto de 2026, plataformas nacionais de gestão para saúde suplementar passaram a anunciar agentes especializados acoplados ao próprio ERP da operadora, cobrindo elegibilidade, contratos, autorizações, TISS e rede credenciada, com validação documental e auditoria médica ainda em desenvolvimento. A discussão saiu de "se" e foi para "onde". Onde fica a fronteira de decisão.
Este texto é a leitura que fizemos dessa fronteira, do ponto de vista de quem vai desenhar o serviço. Não é manual de implementação e não cobre escolha de modelo. Se o assunto é perímetro de execução, sandbox e servidor MCP privado, já escrevemos sobre os pré-requisitos de arquitetura antes do agente rodar. Aqui o recorte é outro: o que muda quando o agente deixa de recomendar e passa a gravar.
Duas permissões que costumam viajar no mesmo token
O padrão que mais vimos em prova de conceito é banal e caro. O agente recebe uma conta de serviço do ERP, e essa conta tem leitura e escrita porque foi criada para uma integração antiga que precisava das duas. Ninguém decidiu dar permissão de escrita ao agente. A permissão veio junto.
O raio de dano dos dois modos não tem comparação. Um agente que lê elegibilidade, contrato, histórico de utilização e código TUSS produz, no pior caso, uma recomendação ruim que um humano descarta. Um agente que grava a guia de autorização de volta no ERP produz, no pior caso, um ato administrativo com efeito contratual sobre o beneficiário e financeiro sobre a operadora.
Mesmo modelo. Mesmo prompt. Mesmo orquestrador. É justamente por isso que a distinção some no design review: do ponto de vista do código, as duas chamadas são um POST no mesmo cliente HTTP.
A separação que defendemos é chata e funciona. Credencial de leitura escopada por beneficiário e por janela de tempo, não por sistema inteiro. Credencial de escrita separada, emitida por operação específica, carregando um motivo estruturado e o identificador do humano que responde por aquele ato. No AI.AGENTS isso aparece como duas classes distintas de ferramenta no registro do agente, e não como duas rotas do mesmo conector, porque a diferença precisa ser visível para quem revisa a configuração, não só para quem lê o log depois.
Uma consequência prática que costuma incomodar o time: o agente vai precisar de mais round-trips e vai ficar um pouco mais lento. Aceitamos essa conta.
O TISS registra o resultado, não o caminho
A RN 501/2022 tornou obrigatório o padrão TISS e revogou a RN 305/2012. Entre as finalidades declaradas do padrão estão padronizar as ações administrativas de verificação, solicitação, autorização, cobrança, demonstrativo de pagamento e recurso de glosa, e compor o registro eletrônico dos dados de atenção à saúde do beneficiário.
Repare no verbo. O padrão registra a ação. Autorizado, negado, em análise, com os campos que a guia define e a versão da tabela que estava valendo. Isso é muita coisa, e é bem menos do que a pergunta que chega quando a decisão é questionada.
O que a guia TISS não guarda é o caminho. Quais registros o agente leu antes de decidir. Em que ordem. Qual versão de terminologia estava carregada no motor naquele instante, o que importa porque a própria RN 501 estabelece que o prazo de implantação de uma atualização do padrão não pode ser inferior a três meses nem superior a doze depois do início de vigência da versão. Ou seja, existe uma janela longa e legítima em que duas versões convivem, assunto que já detalhamos em versionamento de tabela como problema de engenharia.
Traduzindo para o desenho: a trilha de raciocínio é um artefato separado, que a operadora precisa construir e versionar por conta própria. Nenhuma norma entrega isso pronto, e nenhum ERP guarda no lugar certo. Nos projetos em que participamos, o registro documental dessa trilha acaba encostado em AI.DOC, porque o que sobra no fim é um conjunto de evidências que precisa ser classificado, indexado e recuperado sob prazo, não uma tabela de log de aplicação.
Reversibilidade não é rollback
Aqui está a parte que quase nunca entra na primeira versão do desenho.
Se o agente escreve, toda escrita precisa de uma operação compensatória. E a operação compensatória não pode ser apagar o registro. Apagar não reverte nada: destrói a evidência de que a decisão existiu, que é exatamente o que vai ser pedido depois.
Reverter é gravar um evento novo que aponta para o anterior, preserva o original intacto e carrega o motivo e o autor da reversão. Isso soa óbvio escrito assim. Na prática, o caminho mais curto no ERP quase sempre é um UPDATE no registro existente, e o time escolhe o caminho curto porque a sprint acaba na sexta.
A SB 5395 dá uma dimensão financeira a isso que ajuda a convencer quem controla o orçamento: a mesma lei proíbe negativa retroativa de cuidado já autorizado, com penalidade de juros de 1% ao mês. No Brasil não temos dispositivo equivalente com esse desenho, mas a lógica econômica não muda de país. Autorização emitida por engano e procedimento já realizado não voltam atrás por decisão administrativa. O custo já aconteceu.
Então a pergunta de arquitetura, antes de qualquer permissão de escrita ser concedida, é curta. Se este agente errar às 3 da manhã de um sábado, qual é o evento compensatório, quem é o autor identificável dele, e em quanto tempo ele existe?
Onde essa fronteira não resolve nada
Agora a parte incômoda, e acho importante dizer com clareza porque ela enfraquece boa parte do que escrevi acima.
Um agente somente-leitura que recomenda, e cuja recomendação é homologada por um analista com fila de 300 pedidos no dia, é um agente de escrita com passos extras. A fronteira está limpa no diagrama e suja na operação. Se a taxa de concordância humana com a recomendação do agente é de 97%, você não tem revisão humana. Você tem uma assinatura.
E não temos boa resposta para medir isso. Taxa de concordância é proxy fraco: pode significar que o agente é bom, ou que ninguém está olhando. Tempo médio até a decisão ajuda um pouco, taxa de discordância por analista ajuda mais, e nenhum dos dois fecha a questão. Desconfio de quem apresenta esse problema como resolvido.
Há ainda um efeito de deriva que vimos acontecer mais de uma vez. O agente somente-leitura entrega menos valor operacional, os números do primeiro trimestre vêm bons, e a pressão para conceder escrita cresce a cada mês de bom desempenho. A decisão de arquitetura não é tomada uma vez. Ela é corroída aos poucos, sempre com justificativa razoável, até que alguém descubra que a permissão mudou em algum ponto dos últimos dois trimestres e ninguém consegue dizer qual foi a mudança nem quem aprovou.
Contra isso, a única coisa que pelo menos atrasa a erosão é tratar a mudança de escopo de permissão como evento de auditoria com aprovação nomeada, do mesmo jeito que se trata mudança de esquema de banco em produção. É pouco. É mais do que a maioria tem hoje.
O que fica
A escolha do modelo é reversível. Você troca o provedor em uma sprint e refaz os testes. A escolha de onde o agente escreve não é reversível no mesmo prazo, porque ela vira contrato com o beneficiário, registro na guia TISS e, eventualmente, peça processual.
Comece pelo mapa de escrita. Quais operações no ERP o agente pode executar, quem responde por cada uma, e como cada uma se desfaz. Depois discuta o modelo.
Se o objetivo é colocar um agente de IA em operadora de saúde para atuar em análise e autorização de pedidos, o AI.AGENTS foi construído em torno dessa separação: ferramentas de leitura e de escrita registradas como classes distintas, escopo de credencial por operação, motivo estruturado obrigatório em toda gravação, e trilha de raciocínio persistida fora do log de aplicação, para que a reconstituição de uma decisão não dependa de retenção de infraestrutura.
O time da Cygnus roda essa avaliação sobre um recorte do dado real da operadora, com o ERP e a versão de TISS que você usa hoje. O que sai é o mapa de escrita do fluxo escolhido, a lista de operações que precisam de evento compensatório e ainda não têm, e uma comparação entre o que a trilha atual reconstitui e o que ela deixa de fora. Solicitar avaliação do AI.AGENTS.
Sozinhos, combatemos uma fraude. Unidos, eliminamos o problema.