Antes de aprovar o saving que a IA sugeriu: falta contexto

Resumo executivo

• O saving que a IA sugeriu pode estar certo sobre o dado e errado sobre a empresa. O extrato mostra volume, procedimento e custo. Ele não mostra norma coletiva, coparticipação já praticada, rede disponível na praça nem o que já foi tentado.
• O caso não é hipotético, e o mecanismo já estava em 40%. Um gerente de RH extraiu a base do portal da operadora, pediu sugestões a um modelo de linguagem e saiu propondo coparticipação alta em pronto-socorro. A empresa já praticava 40%, e mexer 1 ponto percentual pararia a fábrica.
• A aritmética inverte o sinal: 2 dias contra 1 ano. Pela conta relatada na própria reunião, dois dias de fábrica parada consomem o saving de um ano da iniciativa.
• O mecanismo sugerido tem efeito medido e estreito: 7,15%. Coparticipação de 20% reduziu 7,15% das consultas por pessoa por ano em base de mais de 80 mil indivíduos — e tem pequena influência sobre o que o paciente não controla.
• Contexto é etapa de processo, não bom senso. No NIST AI RMF 1.0, a função MAP existe para estabelecer o contexto antes de qualquer medição de risco, e inclui explicitamente as leis e normas específicas do contexto de uso.

Resposta direta: trate a saída do modelo como proposta, não como decisão, e não aprove nenhum saving antes de responder a cinco perguntas que a base de sinistro não contém — qual norma coletiva está vigente e qual é a data-base; qual mecanismo já está em uso e em que patamar; qual rede existe no município afetado; o que já foi tentado antes e por que parou; e quem é a pessoa que assina a decisão e com qual critério documentado. Se a resposta a qualquer uma delas for "não sei", o número da economia ainda não é um número.

O caso: uma recomendação plausível e uma fábrica parada

O relato abaixo é do diretor médico de relacionamento com clientes da SulAmérica, em um roundtable com a Axenya no RH Summit 2026. Vale ler inteiro porque cada etapa dele é razoável:

"Ele fez um dump automático da base do portal dessa operadora e botou no ChatGPT ou no Gemini, para obter sugestões do que fazer. E uma das sugestões era: você precisa implementar, automaticamente, uma coparticipação muito alta em cima do pronto-socorro. (...) Aí ele, já na segunda-feira, mandando e-mail para tudo que é lado. Aí alguém do relacionamento sindical veio para ele e falou assim: meu amigo, algumas informações para você. Primeiro, a gente já tem 40% de coparticipação em cima de pronto-socorro. (...) A gente tá com um problema sindical do tamanho de um monstro. Se você mexer um ponto percentual nisso daqui, a fábrica para. Então o saving que você queria fazer, a gente perde em dois dias de fábrica parada, o saving de um ano."

Note o que não deu errado. O dado estava correto: a utilização de pronto-socorro realmente escalava. A inferência estava correta: coparticipação é, de fato, o instrumento clássico para conter demanda eletiva. A execução foi rápida, que é o que se pede de um gestor.

O que deu errado é que três informações decisivas não estavam na base, e nenhuma delas é obscura: o patamar de coparticipação já praticado, a existência de norma coletiva sobre o tema e o estado da relação sindical. A recomendação foi ótima para o universo que ela conhecia. Aconteceu de esse universo ser pequeno.

Vale registrar também quem barrou a decisão: não foi um auditor, não foi o jurídico e não foi a operadora. Foi alguém de relacionamento sindical, ou seja, uma pessoa cujo trabalho é justamente guardar o contexto que não está em nenhuma base. Em muitas empresas essa pessoa não é consultada em decisão de benefício porque a decisão nasce como número, e número parece não precisar de interlocutor.

A aritmética que inverte o sinal do projeto

A frase que fecha o relato é a mais importante para quem aprova, porque ela é uma conta: o saving de um ano se perde em dois dias de parada. Dito de outro modo, o projeto tinha retorno anual da ordem de dois dias de produção — e risco de execução capaz de consumir a totalidade dele em 48 horas.

A tabela da abertura desta página é a estrutura mínima desse caso, e a maior parte das análises só preenche a coluna da esquerda. A coluna da direita não é qualitativa por natureza: patamar praticado é um número, data-base é uma data, rede na praça é uma contagem de prestadores e dias de parada é um custo. Nenhum dos quatro é subjetivo. Eles apenas não estão no arquivo que foi analisado.

É por isso que a pergunta certa não é "a IA errou?". A pergunta é "qual era o escopo do que ela viu?" — e a resposta, em qualquer análise sobre extrato de operadora, é sempre a mesma: ela viu o que foi faturado.

O efeito real do mecanismo sugerido é medido, e é estreito

Vale conferir também a promessa. Coparticipação funciona, mas não do tamanho que a intuição sugere e não sobre tudo. Um estudo atuarial publicado na Redeca, da PUC-SP, que revisa a evidência brasileira e projeta cenários por simulação de Monte Carlo com dados de 2015 a 2019, registra duas coisas incômodas para quem espera um corte grande.

A primeira é a magnitude. Acompanhando uma base de mais de 80.000 indivíduos por quatro anos, o trabalho citado no estudo concluiu que uma taxa de coparticipação de 20% produziu redução média de 7,15% no número de consultas por indivíduo por ano. Sete por cento das consultas — não do custo total.

A segunda é o alcance. O mesmo estudo registra que o efeito esperado aparece apenas nas consultas, com pequena influência sobre os componentes de custo que não são controlados pelo paciente. Isso é decisivo no caso do relato: pronto-socorro é justamente o ponto em que a decisão do paciente é menos eletiva e o custo por evento é mais alto. O instrumento age mais na porta em que a demanda é discricionária, e a conta estava concentrada na porta em que ela não é.

Nada disso desqualifica o mecanismo. Apenas o dimensiona: 7% das consultas contra dois dias de fábrica é uma relação de risco e retorno que se avalia em uma linha — depois de existir o número. E é o tipo de parâmetro que um modelo de linguagem não inventa nem consulta sozinho, porque ele não estava na base enviada.

Contexto não é bom senso. É etapa de processo

A tentação é resumir isso a "faltou sensibilidade". A literatura de gestão de risco de IA discorda: contexto é uma etapa nomeada, com produto documentado. No AI Risk Management Framework 1.0 do NIST, a função MAP existe para "estabelecer o contexto que enquadra os riscos relacionados a um sistema de IA". A primeira categoria dela é justamente "contexto é estabelecido e compreendido", com a exigência explícita de documentar as leis, normas e expectativas específicas do contexto de uso. O framework é direto sobre a consequência de pular a etapa: sem conhecimento contextual e sem consciência dos riscos dentro dos contextos identificados, gestão de risco é difícil de executar.

O apêndice que compara risco de IA com risco de software tradicional descreve o caso do relato quase literalmente. Entre os riscos novos, ele lista o fato de que o dado usado para construir o sistema pode não ser representação verdadeira ou apropriada do contexto ou do uso pretendido. A base da operadora é uma representação fiel do que foi faturado. Ela nunca foi uma representação da empresa.

A consequência prática é simples e é de processo, não de ferramenta: o contexto precisa ser escrito antes da análise, não lembrado depois dela. Uma página com norma coletiva vigente, mecanismos já em uso e histórico de tentativas é um documento que serve a qualquer análise futura — inclusive às que serão feitas por modelo.

As duas barreiras que transformam recomendação em proposta

Há um motivo jurídico para o "implemente imediatamente" não existir. Ele tem duas partes.

Alteração de condição de trabalho

O art. 468 da CLT admite alteração das condições do contrato individual de trabalho apenas por mútuo consentimento e desde que não resulte prejuízo, direto ou indireto, ao empregado — sob pena de nulidade da cláusula. E o art. 611-A dá à convenção e ao acordo coletivo prevalência sobre a lei nas matérias que lista. Se o desenho do benefício está em norma coletiva vigente, a mudança tem interlocutor e tem calendário, e nenhum dos dois é definido pela planilha.

Decisão tomada por máquina sobre dado sensível

Dado de saúde é dado pessoal sensível, e o art. 11 da LGPD fecha as hipóteses de tratamento. Mais adiante, o art. 20 acrescenta a camada que interessa a quem aprova: o titular tem direito a solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, e o § 1º obriga o controlador a fornecer informações claras sobre os critérios e procedimentos usados. Uma decisão de benefício derivada de output de modelo, sem critério documentado e sem dono humano, nasce com um pedido de revisão embutido. O limite do que o RH pode ver e cruzar dessa base está detalhado em o que a LGPD permite ao RH saber sobre a saúde do colaborador.

O gate de aprovação, em cinco perguntas

Este é o entregável prático. Antes de assinar qualquer saving derivado de análise automatizada da base de benefícios, exija resposta escrita para as cinco:

1. Qual norma coletiva rege este benefício hoje, e qual é a data-base? Sem isso não existe cronograma, e sem cronograma o saving anual é ficção.
2. Qual mecanismo já está em uso sobre o componente que queremos atacar, e em que patamar? A pergunta que faltou no caso. Mecanismo no teto tem retorno marginal próximo de zero e risco político máximo.
3. Qual é a rede credenciada disponível no município afetado? Encarecer uma porta sem existir outra não redireciona demanda: ela adia cuidado e volta mais caro.
4. O que já foi tentado, quando, e por que foi revertido? A memória organizacional é o único dado que nenhuma base contém e que sempre existe em alguém.
5. Quem assina, com que critério documentado, e o titular do dado consegue pedir revisão? É o requisito do art. 20 da LGPD e é também simples higiene de governança.

Cinco perguntas custam uma reunião. A alternativa custou, no caso relatado, o equivalente a um ano de economia.

O que isso não significa

Não significa não usar. A mesma pessoa que contou o caso é enfática no sentido contrário, e a ressalva dela é a conclusão desta página:

"Façam isso, inclusive, sugiro que vocês façam, é muito legal de fazer isso. Cuidado com a LGPD, cuidado com uma série de coisas, mas vale a pena você pegar uma base e explorar dentro das ferramentas de IA, não tem por que não fazer isso hoje. (...) Mas cuidado, a tomada de decisão é composta por uma série de outras coisas que vão além daquela brincadeira que você tá fazendo no seu ChatGPT."

A distinção é entre explorar e decidir. Explorar base com ferramenta de IA é barato, rápido e formativo — inclusive para tarefas delimitadas, como ler a carta de reajuste com apoio de IA, em que o documento traz o próprio contexto. Decidir é outra operação: ela precisa das informações que estão fora do arquivo, do interlocutor que pode dizer não e do nome de quem assina.

Um bom sinal de que a exploração está madura é a lista de perguntas ficar mais longa depois dela, não mais curta. Quando o output vem em forma de plano fechado e a lista de perguntas encurta, o que aconteceu foi perda de contexto — e, como sempre, ela aparece na fatura de outro departamento. As perguntas que um CFO deveria fazer sobre o plano de saúde da empresa continuam sendo as mesmas com ou sem modelo de linguagem no meio.