Não há stack de prateleira para IA regulada

O mercado quer vender-lhe uma stack. Escolha um fornecedor, adote os modelos dele, faça deployment na região dele, e estará a operar agentes até ao fim do trimestre. Para muitas empresas, é uma resposta perfeitamente boa.

Só que, numa empresa regulada, é uma armadilha, e a razão não é comercial. Que modelos pode usar, e onde estes podem fisicamente correr, é decidido pelo seu regime regulatório e pela sua homologação de segurança, e não por uma omissão de um fornecedor. Uma stack de prateleira traz codificada a resposta de outra pessoa a uma pergunta que só a sua função de compliance pode responder. É por isso que nunca passa na revisão.

Um banco sujeito à DORA e a obrigações de residência de dados precisa de um deployment fundamentalmente diferente do de um hospital, e ambos precisam de algo diferente da arquitetura de referência de um fornecedor. A stack não é um produto que se compra. É um conjunto de decisões que tem de assumir.

O lock-in é um risco de concentração, não apenas comercial

Normalizar num único fornecedor de modelos parece uma simplificação prudente. Num contexto regulado, cria discretamente um risco com que o seu supervisor se preocupa ativamente.

A camada dos modelos é a parte que se move mais depressa em toda a stack. Prenda a sua arquitetura a um fornecedor e ela envelhece ao ritmo desse fornecedor, herda as indisponibilidades desse fornecedor, e depende da disponibilidade continuada desse fornecedor para o servir em termos aceitáveis. Num negócio não regulado, é um incómodo comercial. Sob um regime de resiliência operacional, a dependência de um único terceiro insubstituível é um risco de concentração, e demonstrar que não está exposto a um é quase uma obrigação.

Por isso o agnosticismo quanto ao fornecedor não é um extra que se acrescenta para ganhar poder negocial. É evidência que a sua função de compliance tem de conseguir produzir: é assim que contornamos qualquer fornecedor isolado, e é este o caminho testado que seguiríamos se um deles ficasse inutilizável amanhã.

O gateway de modelos torna os fornecedores intercambiáveis

A resposta ao lock-in é uma única interface interna que todos os agentes invocam, atrás da qual os modelos são intercambiáveis. Anthropic, Mistral, ou um modelo open-source a correr nas suas próprias GPUs, ficam todos atrás da mesma porta. O agente não sabe nem lhe interessa qual respondeu.

Três propriedades separam um gateway real de um decorativo.

Um fallback documentado e testado. Se um fornecedor estiver indisponível ou falhar uma verificação de política, o gateway encaminha automaticamente para uma alternativa. Portabilidade que não foi testada antes de depender dela é um slogan, não um controlo. Sob um regime de resiliência operacional, um fallback automático e testado é quase um requisito.

Pelo menos três opções portáveis documentadas antes de entrar em produção. Não depois. A altura de provar que consegue mudar é enquanto ainda tem a opção de não mudar. Três opções documentadas e substituíveis antes de depender de qualquer uma delas é o que transforma "podíamos mudar" em "já mudámos, aqui está o runbook".

Encaminhamento por sensibilidade, não por conveniência. O gateway decide onde uma carga de trabalho pode correr com base nos dados que transporta, e não em qual fornecedor é hoje mais barato ou mais rápido. Essa decisão pertence à secção seguinte, porque é a que os reguladores escrutinam com mais força.

A topologia de deployment é uma decisão de soberania de dados, encaminhada por classe

Eis a parte que a maioria das arquiteturas de referência erra: escolhem uma topologia de deployment para tudo. É assim que se acaba por sobrecondicionar trabalho barato e não sensível ou, muito pior, por deixar dados regulados chegar a um sítio onde nunca deviam ter ido.

A topologia não é uma decisão. É uma regra de encaminhamento. Os dados são classificados por sensibilidade, e a classificação decide a topologia.

A regra está acima da tabela: classifique os dados, e a tabela diz-lhe onde essa classe pode correr. Um único processo de negócio pode conter passos sensíveis e não sensíveis, por isso o encaminhamento acontece passo a passo, e não uma vez para o sistema inteiro.

A postura que torna isto defensável é o encaminhamento por soberania que falha fechado. Dados regulados e pessoais ficam dentro do seu perímetro por omissão. Só cargas explicitamente não sensíveis podem chegar a um modelo em região externa, e só se o tiver permitido. Quando uma classificação é incerta, o sistema trata os dados como sensíveis e retém-nos. A omissão protege-o, e é preciso uma decisão deliberada e registada para a relaxar. "Os seus dados nunca saem de casa" deixa então de ser uma frase de marketing. É uma arquitetura em que a saída é negada por omissão e permitida apenas por política.

Ser dono da stack é ser dono da saída

Agnóstico quanto ao fornecedor e deployment em qualquer lado só se aguentam se os conseguir provar sob pressão, o que significa que a saída tem de ser real, não retórica.

Duas coisas impedem uma plataforma herdada de se tornar, em silêncio, o lock-in que estava a tentar evitar. Ambas pertencem ao contrato, por escrito.

Escrow e uma saída testada. Código-fonte e pesos em escrow, e um plano de saída documentado e testado. Um caminho de migração que nunca ensaiou é um desejo, não uma garantia.

O ativo é seu. O runtime governado e os agentes são seus para operar. O seu roteiro continua a andar quando o parceiro de implementação sair. Um parceiro sério sujeita-se a ser um terceiro substituível ao abrigo das regras dos seus reguladores, porque é exatamente isso que essas regras exigem dos seus fornecedores críticos.

A questão não é que tenha de construir sozinho todas as camadas. Reconstruir um gateway de modelos, um motor de políticas e uma malha de deployment do zero é cerca de um ano de canalização difícil, a maior parte dela nos detalhes de segurança e compliance que um regulador inspeciona. A questão é que, quem quer que a construa, as decisões continuam suas: que modelos, a correr onde, movidos como. São decisões de compliance vestidas de engenharia.

Por isso, a pergunta não é "que stack devemos adotar?". É se o nosso fornecedor principal de modelos ficasse inutilizável amanhã, por razão comercial, regulatória ou de indisponibilidade, qual é o caminho testado para o seguinte, e está documentado antes de entrarmos em produção? Se não consegue responder a isso por modelo e por classe de dados, ainda não tem uma decisão de deployment. Tem uma esperança de deployment.

Se quiser mapear as suas classes de dados nas topologias permitidas num processo real, marque uma reunião.