Governança de IA
Toda chamada de IA da empresa passa por uma porta só.
A empresa já usa inteligência artificial. A pergunta é se ela sabe quem chama, quanto se gasta, o que sai daqui e o que fazer quando o fornecedor cair. Somos especialistas em implantar essa porta, e ela fica onde você quiser: na sua conta de nuvem, no seu cluster ou no seu datacenter, endurecida com a mesma prática de segurança que sustenta ambiente sob PCI-DSS e ISO 27001.
O ponto de partida
A empresa já usa IA.
Ela só não sabe onde.
Isto não é hipótese, é o retrato que toda descoberta encontra: cada aplicação falando direto com o fornecedor dela, cada credencial guardada num lugar diferente, cada consumo caindo numa fatura diferente. No meio do caminho, o retângulo vazio: o lugar onde alguém poderia perguntar quem chamou, quanto custou e o que foi enviado, e onde hoje não há nada.
Seis origens dentro da empresa chamando quatro provedores de IA diretamente, cada uma com a credencial guardada num lugar diferente e cobrada numa conta diferente.
No meio do caminho há apenas um contorno tracejado e vazio, no lugar exato onde o gateway ficaria. As chamadas atravessam esse espaço sem passar por controle nenhum.
-
Ninguém sabe quanto se gasta
A fatura chega somada. Não há como dizer qual time, qual produto ou qual experiência consumiu o quê, então não há como cortar o que não vale nem defender o que vale.
-
A chave está em todo lugar
Chave de API em repositório, em automação, em planilha e no computador de quem saiu. Sem inventário, revogar uma exige descobrir onde ela está sendo usada.
-
Não há o que auditar
Quando alguém perguntar o que a empresa mandou para um modelo de terceiro, e essa pergunta chega, a resposta precisa existir. Sem porta única, ela não existe.
-
Trocar de modelo é reescrever
Cada aplicação fala direto com o fornecedor dela. Modelo novo, preço melhor ou exigência de contrato viram projeto de engenharia em vez de mudança de configuração.
A porta única
A aplicação deixa de falar com o fornecedor.
Ela passa a falar com a política.
Um endereço interno recebe toda chamada de IA da empresa e decide o que fazer com ela: se a chave pode, se o orçamento permite, se o dado pode sair, qual modelo atende e o que fica registrado. Depois disso, ela sai. Antes disso, ela pode não sair.
Cinco aplicações chamando um único gateway, que aplica identidade, orçamento, política de dado, roteamento e registro antes de encaminhar para três grupos de destino: LLMs de nuvem, modelos abertos, e agentes e servidores MCP.
Uma das cinco chamadas é recusada na porta por estouro de orçamento, antes de sair da empresa.
O que o gateway entrega
Seis controles que só existem
onde existe uma porta única.
-
Custo
Orçamento que existe de verdade
Limite por chave, por time e por projeto, aplicado na chamada e não no relatório do mês seguinte. Estouro é recusado, não descoberto.
- Teto de gasto por chave, time, projeto e período
- Consumo por token atribuído a quem chamou
- Alerta e corte automático ao atingir o limite
- Roteamento por custo: a tarefa vai para a faixa que ela exige
- Cache de resposta para o que se repete
-
Acesso
Chave virtual em vez de chave real
A credencial do fornecedor nunca sai do gateway. Cada aplicação recebe uma chave própria, com escopo, prazo e revogação imediata.
- Chave virtual por aplicação, time ou pessoa
- Lista de modelos permitidos por chave
- Prazo de validade e rotação sem parar a aplicação
- Revogação imediata, sem procurar onde a chave estava
- A credencial do fornecedor fica num lugar só
-
Auditoria
Registro do que foi perguntado
Quem chamou, qual modelo, quando, quanto custou e qual política se aplicou. É o registro que a norma pede e que o jurídico vai pedir antes dela.
- Trilha por requisição, com autor, modelo e custo
- Política de retenção definida por tipo de conteúdo
- Exportação para a ferramenta de observabilidade que a empresa já usa
- Evidência pronta para auditoria de governança de IA
-
Dado
O que sai do perímetro, e o que não sai
Regra de conteúdo aplicada antes da chamada, e não confiada ao desenvolvedor de cada aplicação. Dado sensível para em política, não em revisão de código.
- Mascaramento de dado pessoal antes do envio
- Bloqueio por padrão de conteúdo e por tipo de tarefa
- Escolha de região do provedor, quando ele oferece
- Roteamento de tarefa sensível para modelo local
-
Continuidade
A aplicação não cai porque o fornecedor caiu
Fila alternativa, nova tentativa e distribuição entre provedores. A indisponibilidade de um modelo deixa de ser incidente da empresa.
- Fallback automático entre provedores e regiões
- Nova tentativa com recuo, sem duplicar cobrança
- Distribuição de carga entre chaves e contas
- Limite de vazão por chave, para um time não consumir a cota do outro
-
Independência
Trocar de modelo é configuração
Uma interface única para todos os provedores. A aplicação chama o gateway, e a decisão de qual modelo atende fica na política, não no código.
- Interface compatível em toda a base de aplicações
- Modelo novo entra sem tocar em aplicação
- Modelo aberto auto-hospedado atrás da mesma porta
- Comparação de custo e resultado entre modelos com tráfego real
Como isso aparece
A governança deixa de ser documento
e vira tela.
Política que mora em apresentação não sobrevive ao primeiro trimestre. Depois da implantação, dar acesso, mudar limite e saber quem gastou são três telas, operadas por quem já cuida do ambiente.
01Acesso
Cada aplicação com a chave dela.
A credencial do fornecedor fica guardada num lugar só, e cada aplicação, time ou pessoa recebe uma chave própria. Dar acesso deixa de ser distribuir segredo, e tirar acesso deixa de ser caçar onde ele foi parar.
- Criação, prazo e revogação sem tocar em aplicação
- Lista de modelos permitidos por chave
- Quem usou, quando usou e quanto gastou, por chave
| Chave | Time | Último uso | Gasto / teto |
|---|---|---|---|
| atendimento-prodsk-…9f2a | atendimentoativa | há 2 min | US$ 4.182/ 10.000 |
| copiloto-engsk-…tt09 | engenhariaativa | há 3 min | US$ 6.740/ 12.000 |
| agente-chamadosk-…pq77 | operaçõesativa | agora | US$ 3.301/ 8.000 |
| portal-websk-…7b01 | marketingativa | há 5 min | US$ 1.905/ 5.000 |
| ci-avaliacaosk-…hh55 | qualidadelimitada | há 7 min | US$ 58/ 250 |
| laboratoriosk-…ww21 | pesquisaexpirada | há 38 min | US$ 121/ 500 |
02Política
O limite vale na chamada, não no relatório.
Teto de gasto, limite de vazão, modelos liberados e regra de conteúdo ficam na política da chave. Quando o teto é atingido, a chamada é recusada, e não descoberta no fechamento do mês.
- Teto por chave, time, projeto e ambiente
- Máscara de dado pessoal e bloqueio de injeção de prompt
- Retenção do registro definida por tipo de conteúdo
Limites
produção 6.000 · homologação 2.000 · teste 500
Guardrails
Modelos permitidos
03Consumo
A fatura deixa de chegar somada.
Cada requisição fica atribuída a quem chamou, e o consumo aparece por time, por chave e por modelo. É o que permite cobrar de quem usa, cortar o que não paga e defender o que paga.
- Rateio por área, com número que o financeiro aceita
- Comparação de custo entre modelos com tráfego real
- Exportação para a ferramenta que a empresa já usa
US$ 41.257
Por time
Por modelo
Telas ilustrativas do painel que acompanha a implantação. Os nomes e os valores são fictícios.
Onde isso é usado
A mesma porta resolve
seis problemas diferentes.
- 01
Acabar com a IA de sombra
O primeiro trabalho quase sempre é descobrir o que já está rodando. O gateway transforma uso disperso em uso visível, e é a partir dele que política deixa de ser documento.
- 02
Rateio por área
Cada time enxerga o próprio consumo e responde por ele. Sem isso, IA fica no centro de custo de tecnologia e nunca entra na conta de quem usa.
- 03
Migração entre provedores
Trocar de fornecedor ou dividir tráfego entre dois vira ajuste de política. É o que permite negociar contrato de posição de força.
- 04
Ambiente separado por estágio
Desenvolvimento, homologação e produção com cotas, modelos e políticas diferentes. Teste deixa de gastar orçamento de produção.
- 05
Modelo local no mesmo lugar
Modelo aberto rodando dentro de casa atende pela mesma interface do provedor externo. A tarefa sensível muda de destino sem mudar de código.
- 06
Base para agente
Agente que executa precisa de limite, registro e possibilidade de corte. Subir agente antes do gateway é subir automação sem freio.
Onde ele roda
Por ser aberto,
você escolhe onde ele fica.
Governança de IA não deveria exigir mandar todo o tráfego da empresa para o serviço de mais um intermediário. Como o software é aberto, a topologia é decisão de quem tem o dado, e as quatro abaixo são as que implantamos.
-
O padrão para quem já opera em nuvem
Na sua conta de nuvem
Dentro da sua VPC, sem endereço público, com a saída passando por egress controlado. Nem o tráfego nem o registro atravessam infraestrutura de terceiro, a nossa inclusive.
-
Para quem tem plataforma madura
No cluster que você já tem
Kubernetes ou ECS existente, no mesmo padrão de entrega, observabilidade e alerta do resto da sua plataforma. Sem uma ilha nova para o time aprender a operar.
-
Para restrição regulatória de saída
No seu datacenter
On-premise, com o modelo aberto rodando ao lado da porta. A tarefa que não pode sair do prédio não sai, e continua atendida pela mesma interface das demais.
-
Para quem quer o controle sem o time
Operado pela haapit
Na infraestrutura que sustentamos, com SLA contratado, NOC e SOC 24x7 acompanhando. O controle existe desde o primeiro dia, sem a empresa precisar montar o time para isso.
Quem implanta
O software é aberto.
A implantação é o trabalho.
O LiteLLM é gratuito e qualquer pessoa sobe um contêiner dele numa tarde. O que não vem no contêiner é a decisão de onde ele fica, quem pode chamar, o que é mascarado, para onde vai a trilha, como o segredo é rotacionado, o que acontece quando um provedor cai e como tudo isso é provado a um auditor. É aí que estamos.
-
A empresa não fica presa a nós
Licença MIT, configuração versionada no repositório do cliente e nenhuma peça proprietária da haapit no caminho. Se um dia quiserem levar a operação para outro fornecedor, levam, e é justamente por isso que o cliente confia em colocar toda a IA da empresa atrás dela.
-
Fica onde a empresa quiser
Software aberto significa que a topologia é decisão de quem tem o dado. Não existe obrigação de mandar tráfego para o serviço de mais um intermediário para conseguir governança.
-
A segurança pode ser a nossa, e não a de um catálogo
Em produto fechado, o controle disponível é o que o fornecedor decidiu expor. Com o código aberto, aplicamos a nossa prática: mascaramento, endurecimento, segregação, guardrail próprio e a trilha indo para o SIEM que a empresa já usa.
-
O que falta, escrevemos
A porta tem ponto de extensão antes e depois de cada chamada. Regra que a empresa precisa e que não existe pronta em lugar nenhum entra ali, testada, versionada e sustentada como código de produção.
O que entregamos
LiteLLM licença MIT
- Desenho da topologia, do perímetro e da alta disponibilidade
- Política de acesso, de teto e de retenção, decidida com o cliente antes de virar configuração
- Endurecimento, mascaramento e guardrail próprios
- Integração com o SIEM, a observabilidade e o gerenciador de segredo que já existem
- Migração das aplicações uma a uma, sem janela de indisponibilidade
- Sustentação com SLA, plantão do SOC e revisão periódica de política
model_list: - model_name: redacao-longa # o nome que a aplicação conhece litellm_params: model: bedrock/claude-sonnet aws_region_name: sa-east-1 # o dado fica no Brasil - model_name: redacao-longa # mesmo nome, outro provedor litellm_params: model: azure/gpt-4o api_base: os.environ/AZURE_API_BASErouter_settings: routing_strategy: usage-based-routing-v2 num_retries: 2 # nova tentativa antes de desistirgeneral_settings: master_key: os.environ/LITELLM_MASTER_KEYTrecho ilustrativo. Os dois provedores são publicados com o mesmo nome interno, então a aplicação pede redacao-longa e nunca sabe quem atendeu. As variáveis são preenchidas pelo gerenciador de segredo na subida do serviço, e não ficam em arquivo nem em imagem.
A segurança da porta
Subir o contêiner é fácil.
Esta parte não é.
A porta passa a concentrar a credencial e o registro mais sensíveis da empresa em matéria de IA. Feita sem disciplina, ela não é um controle novo: é um alvo novo. É por isso que quem implanta importa, e é aqui que a nossa prática de segurança entra.
-
Segredo e identidade
A porta concentra a credencial mais sensível da empresa em matéria de IA. Se ela vaza, vaza tudo de uma vez, então o segredo nunca fica onde é conveniente.
- Credencial do fornecedor em gerenciador de segredo, nunca em repositório nem em imagem
- Injeção só em tempo de execução, com rotação que não para o serviço
- Chave virtual de escopo mínimo: modelo permitido, teto e prazo de validade
- Autenticação da aplicação contra o gateway, e não apenas uma chave estática
- Credencial separada por ambiente, sem chave de produção em homologação
-
Rede e perímetro
Uma porta única é também um alvo único. Ela é tratada como serviço crítico exposto, com a mesma disciplina de perímetro de um ambiente sob certificação.
- Sem endereço público: alcançável apenas de dentro do perímetro
- Saída por egress controlado, com lista de destino permitido
- TLS terminado por nós, com cifra em trânsito de ponta a ponta
- Limite de vazão e proteção de borda contra abuso e exaustão de cota
- Região do provedor escolhida por exigência de dado, e não pelo padrão dele
-
Dado e registro
O registro do gateway guarda o que a empresa perguntou aos modelos. Isso é dado sensível por definição, e é tratado como tal, e não como log de aplicação.
- Mascaramento de dado pessoal antes do envio e antes da gravação
- Registro cifrado em repouso, com retenção definida por tipo de conteúdo
- Trilha replicada para o SIEM, fora do alcance de quem administra a porta
- Base de consumo separada da base das aplicações
- Adequação à LGPD tratada no desenho, e não em ajuste depois
-
Operação e verificação
Controle que ninguém testa não é controle. A porta entra no mesmo regime de verificação e plantão dos ambientes que já sustentamos sob contrato.
- Alta disponibilidade em mais de uma zona, com teste de queda
- Configuração versionada em repositório e revisada contra base de endurecimento
- Pentest da própria porta, pelo nosso time de segurança ofensiva
- Guardrail antes e depois da chamada, contra injeção de prompt e vazamento de contexto
- Monitoração no SOC 24x7, com alerta de estouro e de comportamento fora do padrão
A régua é a mesma que usamos em ambiente sob certificação: PCI-DSS, ISO 27001 e SOC, com QSA, CISSP e CISA no mesmo time que opera. Do lado de IA, o desenho é conferido contra o OWASP Top 10 para LLM e o NIST AI RMF.
Exemplos de implantação
Quatro situações,
e a decisão que cada uma exige.
São padrões de implantação, sem nome de cliente: o que interessa aqui é a decisão de arquitetura e de política em cada caso, que é a parte que não vem pronta em nenhuma ferramenta.
- 01
Atendimento com dado de cliente
- A situação
- Assistente que precisa ler o histórico do cliente para responder, com CPF, endereço e dado de pagamento no meio do contexto.
- A montagem
- Porta dentro da VPC do cliente, com região fixada no Brasil e saída por egress controlado.
- A política
- Máscara de dado pessoal antes do envio, modelo econômico para classificar e triar, modelo de fronteira só onde a redação precisa.
- O resultado
- O dado pessoal não sai identificado, e a conta cai porque a maior parte do volume nunca precisou do modelo caro.
- 02
Copiloto para o time de engenharia
- A situação
- Time inteiro querendo assistente de código, cada um com a própria chave, e trecho de código proprietário indo para fora sem controle.
- A montagem
- Porta compartilhada, com chave virtual por pessoa e um modelo aberto auto-hospedado ao lado.
- A política
- Teto mensal por pessoa, e roteamento do código proprietário para o modelo local, pela mesma interface.
- O resultado
- Consumo atribuído por pessoa e por time, e o código que não podia sair deixa de sair, sem tirar a ferramenta de ninguém.
- 03
Agente que executa em produção
- A situação
- Agente que abre e fecha chamado, consulta inventário e altera configuração, ou seja, um agente que age e não apenas responde.
- A montagem
- Chave própria de escopo mínimo, separada da chave das aplicações, com trilha própria.
- A política
- Limite de vazão, guardrail depois da chamada e revogação de chave como botão de parada.
- O resultado
- O agente ganha freio, e o freio é acionável em segundos por quem está de plantão, sem depender de deploy.
- 04
Dois provedores ao mesmo tempo
- A situação
- Dependência de um fornecedor único, com contrato em renovação e nenhum dado próprio para sustentar a negociação.
- A montagem
- Dois provedores atrás da mesma porta, com divisão de tráfego configurável e fila alternativa entre eles.
- A política
- Comparação de custo e de acerto com tráfego real, e queda de um provedor atendida pelo outro automaticamente.
- O resultado
- A renovação passa a ser negociada com número medido em casa, e a indisponibilidade de um fornecedor deixa de ser incidente.
Governança
A norma pede evidência.
É aqui que ela nasce.
A ISO/IEC 42001 pede registro de decisão, controle de acesso, gestão de risco e monitoramento do que o sistema de IA faz. Sem uma porta única, cada um desses itens precisa ser provado aplicação por aplicação, e na prática não é provado. O gateway é a camada onde essa evidência nasce sozinha, e é por isso que ele costuma ser o primeiro item do caminho de adoção, e não o último.
Ler o paper sobre a ISO/IEC 42001Como implantamos
Cinco etapas, e a política
é decidida antes da configuração.
- 01
Descoberta
Levantamento do que já usa IA na empresa, de qual chave, com qual gasto e sob qual política. Quase sempre há mais do que o inventário indica.
- 02
Política
Quem pode chamar o quê, com qual teto, com qual retenção e qual dado nunca sai. A política é decidida antes de virar configuração.
- 03
Implantação
Gateway em alta disponibilidade, na nuvem ou dentro do perímetro, com chave virtual por aplicação e a credencial do fornecedor isolada.
- 04
Migração
As aplicações passam a apontar para o gateway, uma a uma, sem janela de indisponibilidade. A chave direta é revogada ao fim de cada uma.
- 05
Operação
Painel de consumo, revisão periódica de limite e de política, e sustentação com o mesmo SLA do resto da operação.
Comece pela descoberta, sem custo.
Um levantamento do que já usa IA na sua empresa, com qual chave, sob qual gasto e sob qual política. É o retrato que precede qualquer decisão de governança, e ele costuma surpreender.