O problema do “wrapper” do LLM: por que a IA pronta para demonstrações falha na produção regulamentada

Sua demonstração piloto foi um sucesso. O modelo respondeu a todas as perguntas do roteiro, a plateia concordou com a cabeça e o projeto seguiu para a fase de produção. Então, alguém com autoridade para auditoria perguntou por que a IA havia dito aquilo a um cliente, e a resposta sincera foi um encolher de ombros.

Um wrapper de LLM é uma IA corporativa que encaminha as consultas dos usuários a um grande modelo de linguagem durante a execução e apresenta a resposta gerada como uma resposta final, sem uma camada de conhecimento regulamentada entre elas.

Essa é a arquitetura subjacente à maioria das soluções de IA corporativas lançadas nos últimos dois anos. É também a arquitetura que entra em colapso no momento em que um regulador, auditor ou responsável pela conformidade faz uma pergunta: por que a IA disse isso?

Pontos principais

• Um wrapper LLM gera respostas em tempo de execução por meio da interação com um modelo de base. A fluência é real. A precisão, a rastreabilidade e a auditabilidade exigidas pela produção regulamentada não são propriedades do wrapper. Elas são incorporadas como medidas de segurança.
• A falha é estrutural, não um bug de implementação. Prompts melhores, janelas de contexto mais longas e mais medidas de segurança não alteram a propriedade subjacente: toda resposta é gerada, nunca recuperada de uma fonte controlada.
• A arquitetura centrada no conhecimento inverte o processo de design. O conteúdo é captado, estruturado em intenções controladas e vinculado à sua fonte antes de qualquer interação com o cliente. No momento da execução, o sistema recupera uma resposta pré-validada, de modo que cada resposta remete à fonte que a produziu.
• É possível diagnosticar um wrapper mesmo sem o diagrama de arquitetura do fornecedor. Peça a fonte por trás de uma resposta específica e observe se a resposta recebida é clara e repetível ou se a pergunta é encaminhada discretamente para o provedor do modelo.
• Veja em uma demonstração como o Encore resolve o problema do invólucro.

O que é o problema do wrapper LLM?

O problema do “wrapper” LLM é o padrão em que a IA corporativa é construída como uma camada fina de aplicação sobre um modelo de base. As consultas dos usuários são encaminhadas ao modelo em tempo de execução, e a resposta gerada é enviada diretamente de volta ao cliente.

Em uma demonstração, isso é indistinguível de qualquer outro assistente de IA. Na produção regulamentada, a peça que falta se torna o problema em si. Não há nenhuma fonte regulamentada por trás da resposta.

A lacuna entre a demonstração e a produção é uma lacuna arquitetônica. Os wrappers funcionam nas demonstrações porque estas são controladas. A produção real revela a ausência de proveniência.

Os setores regulamentados não aceitam padrões gerativos. Serviços financeiros, turismo e hotelaria, jogos de azar e jogos online, além de SaaS B2B com clientes regulamentados, operam sob estruturas regulatórias que exigem explicabilidade — algo que um wrapper não é capaz de proporcionar.

O problema do wrapper não é um problema de seleção de modelo. Trocar um modelo de base por outro — o GPT pelo Claude, ou o Claude pelo Llama — não altera a arquitetura. A falha está na ausência de uma camada de conhecimento regulada, e não no modelo.

5 motivos pelos quais os wrappers de LLM apresentam falhas em ambientes de produção regulamentados

Esses são modos de falha estrutural. Eles ocorrem independentemente da qualidade da implementação do wrapper.

1. Não há vinculação com a fonte nas respostas geradas. Cada resposta é uma síntese probabilística. O wrapper não pode indicar ao examinador o documento, a política ou o item de conhecimento específico que gerou uma determinada resposta, pois essa vinculação não existe na arquitetura.
2. A alucinação é uma característica do projeto, não um caso extremo. Gerar uma resposta em tempo de execução introduz uma certa probabilidade de invenção em cada interação. As medidas de proteção reduzem a frequência. Elas não eliminam a causa arquitetônica.
3. As trilhas de auditoria registram a atividade, não a proveniência. Os registros do wrapper registram o que o usuário solicitou e o que o modelo retornou. Eles não registram por que o modelo retornou essa resposta, pois não é possível analisar o modelo nesse nível.
4. O comportamento não é repetível entre versões. Os modelos de base são atualizados e tornam-se obsoletos. Um wrapper que fornecia uma resposta aceitável em março pode fornecer uma resposta diferente em junho, sem que haja qualquer alteração da sua parte. Em contextos regulamentados, essa variação constitui, por si só, um evento de conformidade.
5. A postura de conformidade é herdada, não conquistada. Os fornecedores de soluções de encapsulamento geralmente herdam suas certificações do provedor do modelo. Essa postura abrange a infraestrutura. Ela não abrange a governança de resposta na camada de aplicativos, que é exatamente o que os auditores realmente questionam.

Como saber se a IA da sua empresa é apenas uma camada superficial em torno de um LLM

Você não precisa do diagrama de arquitetura do fornecedor para diagnosticar isso. Faça essas perguntas e veja com que rapidez você receberá respostas claras.

• O fornecedor pode apresentar, mediante solicitação, o documento de origem exato que fundamenta uma resposta específica?
• A mesma pergunta sempre resulta na mesma resposta, ou a formulação varia?
• Quando o modelo subjacente é atualizado, sua implantação é revalidada ou o comportamento simplesmente muda?
• O registro de auditoria é um registro de proveniência ou apenas uma transcrição das entradas e saídas?
• A documentação de conformidade abrange a camada de aplicação ou apenas a infraestrutura do provedor do modelo?

Se as respostas forem vagas, demoradas ou forem discretamente redirecionadas de volta ao provedor do modelo, você está executando um wrapper.

Por que a engenharia de prompts e as medidas de proteção não conseguem resolver o problema do “wrapper”

As medidas de mitigação ajudam de forma marginal. Nenhuma delas altera a arquitetura, pois cada uma atua após a decisão de projeto que gerou o problema.

• O problema da proveniência. A engenharia de prompts altera o que o modelo percebe. Ela não atribui uma fonte à resposta. Mesmo um wrapper com prompts perfeitos ainda produz uma resposta gerada sem nenhum documento de referência por trás. Um órgão regulador não aceita “nós o instruímos cuidadosamente” como substituto para “aqui está a fonte”.
• O problema do não determinismo. Os mecanismos de proteção filtram os resultados após sua geração. Duas consultas idênticas ainda podem produzir duas respostas aceitáveis diferentes, nenhuma delas repetível sob demanda. A repetibilidade é um requisito regulatório, não um recurso de qualidade que seria bom ter.
• O problema da divergência de versões. Quando o modelo subjacente é atualizado, todos os wrappers criados com base nele herdam o novo comportamento, quer você queira ou não. O código de prompt escrito para uma versão do modelo não é portável. A divergência de versões sem revalidação constitui uma falha de controle.
• O problema de custo e latência. As medidas de mitigação se acumulam. Prompts mais longos custam mais tokens, mais restrições aumentam a latência e a reclassificação exige mais recursos computacionais. Um wrapper reforçado para fins de conformidade faz, em tempo de execução, a cada chamada, o que um sistema baseado em conhecimento fazia uma única vez durante a ingestão.

O que a produção regulamentada realmente exige

Três funções aprovam o uso de IA que envolve dados regulamentados, e cada uma delas impõe uma exigência diferente e inegociável.

O CISO e o diretor de riscos precisam de provas, não de garantias.

• Um histórico completo das conversas, com indicação da fonte em cada resposta.
• Comportamento determinístico em consultas repetidas.
• Mapeamentos de controle documentados para as estruturas regulatórias sob as quais você opera, incluindo as expectativas do CFPB em relação a ações adversas, a gestão de risco de modelo conforme a SR 11-7, a transparência prevista no Artigo 13 da Lei de IA da UE, a integridade do processamento conforme a norma SOC 2 e os registros de processamento previstos no Artigo 30 do GDPR.
• Residência de dados, com implantação no local ou em nuvem privada, conforme exigido pela legislação local.

O responsável pela experiência do cliente (CX) e pelas operações do contact center precisa de precisão que se mantenha mesmo em grande escala.

• Respostas nas quais os clientes confiam logo na primeira interação, e não apenas durante uma demonstração.
• Resolução no primeiro contato mensurável, com um aumento de +35% na resolução no primeiro contato e uma melhoria de +30% na satisfação do cliente (CSAT), como resultados comprovados, e não apenas promessas do fornecedor.

O CIO e o COO precisam de sustentabilidade nos investimentos.

• Uma plataforma projetada para ser independente de modelos, de modo que o conjunto de modelos possa mudar sem a necessidade de revalidar toda a implantação.
• Pronto para produção em dias, e não em meses, com mais de 850 integrações corporativas, implantação +75% mais rápida e redução de +50% nos custos indiretos.

O Encore foi desenvolvido exatamente para atender a esses requisitos. Veja como ele se adapta aos seus controles.

Como o Encore resolve o problema do wrapper de LLM

O Inbenta Encore foi desenvolvido de maneira oposta. O padrão do setor é o “LLM-first”: escolher um modelo, integrá-lo à recuperação de conteúdo, direcioná-lo para o conteúdo e torcer para que dê certo. O Encore inverte esse modelo.

• O conhecimento em primeiro lugar, o LLM é opcional. O conteúdo de origem é importado, estruturado e convertido em intenções controladas e vinculadas à fonte antes de qualquer interação com o cliente. No momento da execução, o Encore recupera uma resposta pré-validada. O modelo lida com a orquestração e a formulação da resposta, não com o conteúdo da resposta em si.
• Caixa de vidro, não caixa preta. Cada resposta remete à intenção específica e à fonte que a gerou, e cada caminho de decisão pode ser examinado. Um responsável pela conformidade ou um auditor externo pode ver exatamente por que o sistema disse o que disse. Essa é a arquitetura, não uma camada de relatórios adicionada posteriormente.
• Inteligência Programada, com tecnologia da arquitetura dual-LLM da Encore. A Encore alterna entre a recuperação determinística e a formulação generativa com base no contexto. Utiliza a abordagem determinística quando é necessária precisão, como em respostas regulamentadas ou auditáveis. Recorre à abordagem generativa quando a linguagem aberta agrega valor. É a plataforma que gerencia essa alternância, não você.
• Projetado para ser independente de modelos. O Encore trata a camada de modelos como substituível, avalia os modelos disponíveis em relação ao seu caso de uso e pode alternar entre eles. Seu investimento não se torna um passivo quando o cenário de modelos muda. É a orquestração de IA que faz o trabalho.
• A Engenharia do Conhecimento como camada de dados governada. O conhecimento corporativo é estruturado, organizado e governado por meio da Engenharia do Conhecimento, resultando em intenções prontas para produção. Cada intenção contém links para as fontes, histórico de versões e um registro pronto para auditoria sobre como foi criada.
• Pronto para produção em dias, não em meses. O conteúdo é importado rapidamente para intents ativos e controlados, e mais de 850 integrações pré-configuradas se conectam ao seu CRM, CCaaS e sistemas corporativos. A orquestração pré-configurada também se conecta à infraestrutura obsoleta do contact center sem a necessidade de uma substituição completa da plataforma.
• Comprovação em um ambiente de produção regulamentado. A GOL Airlines lida com mais de 10 milhões de consultas por ano, e a operação OPPLUS do BBVA reduziu as escalações no atendimento ao cliente em 84%. A arquitetura se mantém estável em grande escala, em setores regulamentados, sob condições reais de auditoria.

É justamente essa preparação para o ambiente corporativo que fez com que o Inbenta Encore recebesse o Prêmio TSIA Star na categoria “Inovador do Ano em Sucesso Digital do Cliente”.

Se sua próxima decisão arquitetônica for tomada com a presença do CISO, teste o Encore em seu próprio cenário de auditoria.

Perguntas frequentes

O que é um wrapper de LLM na IA corporativa?

Um wrapper LLM é uma IA corporativa que envia sua consulta a um modelo de base durante a execução e retorna o texto gerado como resposta, sem nenhuma camada de conhecimento regulamentada no meio. A fluência é real, mas nada vincula a resposta a uma fonte aprovada. Essa lacuna é o que causa falhas na produção regulamentada.

Por que os wrappers de LLM falham em produção?

Eles falham por motivos estruturais, não por causa de bugs. Cada resposta é gerada, em vez de ser recuperada de uma fonte controlada; portanto, não há proveniência, o comportamento não é repetível entre as versões do modelo e os registros de auditoria capturam a atividade, em vez de explicar por que uma resposta foi dada. As medidas de proteção reduzem os sintomas, não a causa.

O que é um sistema de IA do tipo “caixa de vidro”?

Um sistema de IA do tipo “caixa de vidro” é aquele cujo processo de tomada de decisão foi projetado para ser examinável. É possível mostrar qual intenção orientou e qual fonte gerou uma determinada resposta. Isso contrasta com a “caixa preta”, que gera respostas de forma probabilística e só consegue oferecer uma explicação aproximada após o fato.

O que significa “arquitetura centrada no conhecimento”?

A abordagem “conhecimento em primeiro lugar” significa que o conteúdo de origem é captado, estruturado em intenções regulamentadas e vinculado à sua origem antes de qualquer interação com o cliente. No momento da execução, o sistema recupera uma resposta pré-validada em vez de gerar uma nova, de modo que todas as respostas sejam precisas, repetíveis e rastreáveis até sua fonte.

Em que o Encore difere de um wrapper de LLM?

O Encore prioriza o conhecimento e considera o LLM opcional. Ele recupera respostas pré-validadas e vinculadas à fonte, em vez de gerá-las em tempo de execução, e o modelo se encarrega da orquestração e da formulação das respostas. Cada resposta é rastreável até sua fonte, de modo que o sistema é auditável por meio de sua arquitetura, e não por meio de uma camada de registro de eventos adicionada posteriormente.

As medidas de proteção podem tornar um wrapper de LLM seguro o suficiente para setores regulamentados?

As barreiras de proteção filtram os resultados após a geração, reduzindo assim as chances de uma resposta incorreta, sem, no entanto, agregar proveniência ou repetibilidade. A produção regulamentada exige respostas auditáveis, rastreáveis e justificáveis, que são propriedades arquitetônicas. Um wrapper não consegue atingir esse padrão simplesmente acumulando mais barreiras de proteção.