De acordo com uma pesquisa da McKinsey, 88% das empresas utilizam Inteligência Artificial (IA), mas apenas 1% atingiu a maturidade. Existe um abismo entre "experimentamos o ChatGPT" e "um sistema corporativo funcional", e na maioria das vezes, esse abismo está relacionado a questões de segurança de dados e conformidade com a Lei Geral de Proteção de Dados (LGPD) no Brasil (equivalente à 152-FZ na Rússia). O que fazer quando o departamento de segurança bloqueia qualquer Large Language Model (LLM) externo? Neste artigo, apresentamos três abordagens arquitetônicas que funcionam em corporações russas e a experiência da Alpina Digital, que passou por todas elas em dois anos.
Meu nome é Jemal Khamidun, sou CPO da AlpinaGPT e Head of AI na Alpina Digital. Desde 2023, implementamos IA em nossa própria produção de livros e em empresas clientes – de editoras a setores farmacêutico e de varejo. Este artigo é um concentrado do que aprendemos sobre a segurança de IA corporativa ao trilharmos o caminho desde os primeiros pilotos até a operação industrial dentro do perímetro do cliente.
Por que a maioria dos pilotos de IA não chega à operação industrial? A situação é típica: uma empresa lança um piloto, dois ou três departamentos experimentam LLMs, surgem as primeiras demonstrações impressionantes – e então tudo para. De acordo com a pesquisa da McKinsey, 88% das empresas já utilizam IA em pelo menos um processo, e apenas 1% atingiu a maturidade – o estágio em que as redes neurais funcionam como parte do perímetro industrial, e não como um brinquedo nas mãos de entusiastas. Isso significa que, entre "experimentamos" e "implementamos", 87 de 88 empresas desistem. O principal obstáculo nesse caminho não é a qualidade dos modelos nem o preço. A qualidade dos modelos hoje é mais do que suficiente para a maioria das tarefas. O preço caiu tanto que um funcionário com todas as redes neurais de ponta custa menos do que uma assinatura de um modelo estrangeiro. O obstáculo é a segurança da informação e a conformidade com a legislação: para onde vão os dados do funcionário, como garantir a LGPD, o que fazer com segredos comerciais, como explicar ao departamento de segurança que o perímetro externo é seguro. Quando lançamos o AlpinaGPT no mercado, pensávamos que a principal questão seria "qual modelo é melhor". Descobrimos que a principal questão é "como fazer com que nosso CISO permita que isso seja lançado?". E é a partir daí que qualquer projeto de implementação de IA corporativa deve começar.
Para onde fisicamente vão as solicitações dos usuários? Quem e como pode acessar esses dados? A modelo é treinada com as solicitações corporativas? Onde são armazenados os históricos de chat e quem os administra? Como é garantida a conformidade com a LGPD e as políticas internas? O que acontece em caso de vazamento da conta de um funcionário?
"Einstein com demência": como realmente funciona o acesso a LLMs estrangeiras Para falar sobre segurança de forma mais concreta, é preciso entender como tecnicamente funciona o acesso a modelos como OpenAI, Anthropic ou Google. A maioria dos medos e mitos aqui se baseia no fato de que, dentro da empresa, misturam-se duas formas completamente diferentes de interagir com LLMs: através da interface do usuário (aplicativo ChatGPT, Claude.ai) e através de uma chave de API. São produtos diferentes com regras de processamento de dados diferentes.
A analogia mais precisa é a seguinte. Atrás de uma porta fechada, senta-se Einstein – um modelo muito inteligente. Só se pode acessá-lo com uma chave. O provedor de IA tem muitos desses Einsteins, e eles estão atrás de portas diferentes. Nós, como empresa, temos uma chave de API: compramos e agora podemos abrir a porta, fazer uma pergunta a Einstein e obter uma resposta. Mas há um detalhe: é um Einstein com demência. O cérebro é genial, mas não tem memória. Ele responde à solicitação, esquece-a e segue em frente. A solicitação do usuário não fica "na cabeça dele", não é usada para retreinamento, não entra no espaço vetorial comum.
Assim funciona o acesso via API – ele é regulado por contratos públicos dos provedores e não retreina o modelo com as solicitações. Mas quando um funcionário baixa o aplicativo ChatGPT em seu laptop e trabalha lá pessoalmente – o modelo nesta interface é retreinado com os dados do usuário, forma uma memória local, e se alguém invadir sua conta, terá acesso a todas as conversas, arquivos e fotos que o funcionário enviou para lá. A maioria dos "temores" sobre "vazamentos no ChatGPT" se refere a este cenário, e não ao API.
Dessa analogia simples, surge a primeira conclusão prática. Proibir os funcionários de usar o ChatGPT pessoal é correto, mas insuficiente. Se nada for oferecido em troca, eles continuarão a usá-lo secretamente, porque as tarefas não desapareceram. A arquitetura corporativa deve oferecer uma alternativa: os mesmos cérebros, mas através de um canal controlado.
Abordagem 1: Modelos estrangeiros via gateway de API corporativo A primeira abordagem arquitetônica é a mais rápida de instalar. A empresa obtém acesso a modelos estrangeiros (GPT, Claude, Gemini) através de um gateway corporativo com chaves de API em vez de assinaturas pessoais. As solicitações são roteadas através de hubs em jurisdições amigas, o tráfego de API despersonalizado, sem vínculo com o funcionário, vai para o provedor, o histórico de chat permanece na Rússia nos servidores do serviço, e o retreinamento do modelo com dados corporativos não ocorre. Legal e tecnicamente – é uma história completamente diferente do que uma conta pessoal do ChatGPT, embora à primeira vista pareça a mesma coisa.
A abordagem é adequada para empresas onde a qualidade das respostas é crítica, mas a localização física do modelo não é. Isso é típico para redações, marketing, análise, P&D, equipes de produto – onde quer que trabalhem com informações públicas, dados abertos, conceitos e ideias, e não com dados pessoais de cidadãos ou segredos de estado. Condições de aplicabilidade: a política interna da empresa permite o processamento dessa classe de dados no exterior, o departamento de segurança está pronto para realizar uma auditoria e assinar a solução arquitetônica.
Quando a abordagem não é adequada: bancos e seguradoras com dados pessoais em massa, empresas estatais, defesa, desenvolvedores de infraestrutura crítica. Para eles, são necessárias as outras duas opções.
| Parâmetro | ChatGPT/Claude Pessoal | Gateway Corporativo via API |
|---|---|---|
| Retreinamento com solicitações | Sim | Não (por contrato do provedor) |
| Onde o histórico é armazenado | Na conta do provedor | No perímetro do serviço na Rússia |
| Visibilidade para SOC/DLP | Nula | Completa (logs, auditoria) |
| Acesso aos chats do funcionário | Apenas do funcionário | Por papéis + admin da empresa |
| Controle de papéis e acessos | Não | Sim (RBAC) |
| Conformidade com LGPD | Não previsto | Alcançável com configuração correta |
Comparação de acesso pessoal e corporativo ao mesmo modelo
Abordagem 2: Modelos russos e open-source on-premise A segunda abordagem é a localização completa. Os modelos são implantados nos servidores da empresa, os dados nunca saem do perímetro. Existem duas opções aqui: modelos comerciais russos (YandexGPT, GigaChat) ou modelos open-source implantados em GPUs próprias (Llama da Meta, Mistral, Qwen da Alibaba, DeepSeek). Legalmente limpo, atende à LGPD sem ressalvas, passa pela auditoria do departamento de segurança sem problemas.
O preço dessa abordagem é um compromisso na qualidade. Os modelos russos estão ativamente alcançando os líderes, mas em benchmarks abertos ainda ficam atrás de GPT e Claude em tarefas complexas de raciocínio, geração de código e trabalho com contexto longo. Modelos open-source se aproximam dos líderes, mas exigem infraestrutura séria: para o funcionamento normal de modelos 70B, são necessárias GPUs de classe A100/H100 ou várias RTX 4090, uma equipe MLOps especializada, monitoramento, atualizações.
Quando essa abordagem é justificada: processamento de dados sensíveis que em princípio não podem sair do perímetro – registros médicos, transações financeiras, correspondências confidenciais, textos originais sob NDA. Também – empresas onde o departamento de segurança categoricamente não aceita a arquitetura com API externo em qualquer forma. A limitação real desse caminho é o custo de propriedade: apenas as GPUs custam milhões, mais os salários da equipe, mais eletricidade e refrigeração.
| Tipo de modelo | Qualidade | Custo de propriedade | Conformidade com LGPD |
|---|---|---|---|
| GPT / Claude (via API) | Nível superior | Baixo (apenas tokens) | Via gateway corporativo |
| YandexGPT / GigaChat | Médio | Médio (licenças) | Completa |
| Open-source 70B+ on-prem | Alto | Muito alto (GPU, MLOps) | Completa |
| Open-source 7-13B on-prem | Médio | Médio (uma GPU) | Completa |
TCO e qualidade para três classes de modelos
Abordagem 3: Arquitetura híbrida – o que nós escolhemos no final A terceira abordagem surge da compreensão de que diferentes tarefas têm diferentes sensibilidades aos dados. Gerar uma ilustração para uma apresentação – nenhum dado confidencial, qualidade máxima necessária, modelo estrangeiro de ponta via API é ideal. Processar o manuscrito de um autor que ainda não foi publicado – é um segredo comercial, um modelo local no perímetro é necessário. Em seguida: resumir um relatório público de vendas – pode ser via API, resumir uma base de clientes com dados pessoais – apenas on-premise.
A arquitetura híbrida se parece com isto: uma interface para o usuário, sob o capô – um roteador de solicitações que, com base na política da empresa, envia a solicitação para a API externa, para um modelo on-premise local, ou a bloqueia até a decisão do funcionário. Antes do próprio modelo, há uma camada de pré-moderação: um agente que verifica a solicitação quanto à confidencialidade. Se sinais de dados sensíveis (nomes, números de conta, exportação do CRM) forem encontrados no texto, a solicitação é automaticamente redirecionada para o modelo local ou devolvida ao usuário com um aviso.
Nós caminhamos para essa arquitetura por dois anos e a reunimos em um produto, para não ter que reconstruí-la para cada cliente. AlpinaGPT é essa plataforma: uma interface para os funcionários, sob o capô – roteamento de solicitações entre API externa e modelo local de acordo com a política da empresa, pré-moderação antes de enviar para o modelo, integração DLP, acesso por papéis, chats no perímetro do cliente. É implantado na nuvem para equipes onde a API externa é permitida, ou on-premise – para requisitos de segurança maduros. Até hoje, mais de 40 implementações corporativas em setores farmacêutico, de varejo, fintech e de mídia passaram por essa arquitetura.
O híbrido tem uma desvantagem honesta – é mais complexo de projetar. É preciso classificar os dados desde o início, descrever as políticas de roteamento, aprová-las com o departamento de segurança, escolher um modelo local para a carga de trabalho, garantir o SLA para ambas as camadas. Não é um MVP rápido "em duas semanas", é um projeto arquitetônico completo de 2 a 4 meses. Mas em troca, a empresa obtém uma solução onde nenhuma das abordagens 1 ou 2 funciona isoladamente: a qualidade dos modelos de ponta onde é possível, e a localização onde é obrigatório.
O que é necessário em qualquer abordagem: medidas organizacionais e técnicas Quando ajudamos as empresas a implementar IA, vemos um erro típico: foco apenas na pilha tecnológica. Implantaram sua própria compilação – e pensam que a tarefa está resolvida. Na prática, metade do sucesso é preparação organizacional, e sem ela a tecnologia não funciona, por melhor que tenha sido projetada.
Política de Implementação de IA. Este é um documento formalizado: quais classes de dados podem ser processadas em IA, quais não podem, o que é considerado um incidente, como reagir a um vazamento. Sem uma política, cada funcionário toma sua própria decisão, e após meio ano, a empresa acumula uso de IA "sombra" que é impossível de controlar.
Papel do Chief AI Officer. Em grandes empresas, surge uma posição separada – um especialista responsável pela implementação de redes neurais e desenvolvimento da estratégia de IA. Importante: não é um profissional de TI puro. A maior parte do trabalho é gestão de mudanças, treinamento, combate aos medos dos funcionários, construção de processos. A tecnologia aqui é uma ferramenta, não um fim em si mesma.
Classificação de dados e treinamento. Antes de lançar a plataforma, cada classe de dados deve ser marcada: "pode ser enviada para modelos públicos", "pode ser enviada apenas para modelos locais", "não pode ser processada em IA de forma alguma". Todos os funcionários passam por treinamento no padrão corporativo de trabalho com IA – caso contrário, qualquer arquitetura vazará através do elo mais fraco. Em nossa experiência, um curso de 4 a 6 horas por funcionário se paga no primeiro trimestre devido à qualidade das solicitações e à redução de incidentes.
Camada técnica. Registro de todas as solicitações, acesso por papéis, integração DLP, criptografia de chats, agente de pré-moderação antes dos modelos, auditoria regular de uso. Sem registro, é impossível investigar incidentes. Sem RBAC, qualquer estagiário tem acesso ao modelo mais caro e consome tokens. Sem pré-moderação, um funcionário pode acidentalmente enviar dados pessoais para uma API externa – e formalmente violar a LGPD.
Checklist para implementação segura de IA:
- Política de implementação de IA aprovada com classes de dados e regulamentos de resposta.
- Responsável pela estratégia de IA (CAIO ou equivalente) nomeado.
- Classificação de dados por níveis de sensibilidade realizada.
- Todos os funcionários passaram por treinamento obrigatório no trabalho com IA.
- Registro, RBAC, criptografia de chats ativados.
- Sistema DLP integrado ao gateway de IA corporativo.
- Pré-moderação de solicitações funcionando antes do envio para o modelo.
- Auditoria regular de uso – pelo menos uma vez por trimestre.
O que a arquitetura correta proporcionou no final: números de nossa implementação Todas essas conversas sobre arquitetura fazem sentido apenas em um caso – se no final houver um resultado mensurável. Vou contar sobre nosso próprio caso, porque sobre os outros só posso falar em termos gerais sob NDA.
O núcleo do negócio da Alpina Digital é a produção de livros. O ciclo – da compra de direitos à publicação – tradicionalmente levava cerca de 9 meses. Este é um processo de investimento: o dinheiro foi investido, o livro ainda não gera receita, a rotatividade de capital é lenta. Quando o boom dos LLMs ocorreu em 2023, lançamos experimentos internos: onde, neste ciclo, a IA poderia acelerar o trabalho sem perda de qualidade – edição, revisão, anotações, tradução, materiais de marketing, design.
Em dois anos, passamos pelo mesmo caminho que agora descrevemos para as empresas. Primeiro, houve o caos com assinaturas pessoais. Depois – gateway corporativo com API. Depois – adicionamos um modelo local para manuscritos sensíveis sob NDA. A arquitetura final é um híbrido: AlpinaGPT como interface única, APIs externas para geração de ilustrações, textos de marketing e traduções, modelo local – para trabalhar com textos de autores não publicados.
Resultado: ciclo de produção de livros – de 9 meses para 2 meses. Isso é uma aceleração de 4,5 vezes com manutenção da qualidade. A rotatividade de capital aumentou correspondentemente, porque cada livro começa a retornar os investimentos significativamente mais cedo. Este não é um número de marketing – é um indicador operacional que vemos em nosso próprio P&L.
Economia. O uso de nossa própria plataforma em vez de assinaturas dispersas nos deu uma economia de 8 vezes. Anteriormente, equipes separadas compravam assinaturas de US$ 120 para ChatGPT, Claude, Midjourney – no total, para toda a empresa, saía cerca de 800 mil rublos por mês. Através do gateway corporativo com chaves de API, gastamos cerca de 100 mil rublos por mês em tokens, a preço de custo. E ao mesmo tempo, temos acesso a todos os modelos de ponta de uma vez, e não a um escolhido por cada equipe.
Período de retorno do investimento com a arquitetura correta – cerca de 6 meses para uma corporação típica de 100 funcionários. Isso é mesmo sem considerar a aceleração dos processos principais, apenas pela economia de assinaturas dispersas e eliminação do uso "sombra".
Recomendações finais:
- Comece não pela escolha do modelo, mas pela classificação de dados e política de segurança.
- Não contraponha API e on-premise – construa um híbrido para cenários reais.
- Gateway de API corporativo ≠ ChatGPT pessoal, diferencie isso na comunicação com o CISO.
- Inclua o treinamento de funcionários no roteiro – sem ele, qualquer arquitetura vazará.
- Calcule o retorno do investimento não apenas pelas assinaturas, mas também pelos processos principais – o efeito principal está lá.
Se você está na fase de "pilotos existem, operação industrial não" – o bloqueador mais comum não está na tecnologia, mas na solução arquitetônica de segurança. Se você quiser discutir sua situação – escreva para a equipe AlpinaGPT, analisaremos gratuitamente: qual arquitetura se adequa aos seus dados, como passar pela auditoria do departamento de segurança, quais modelos e em qual camada manter, por onde começar. Você pode imediatamente experimentar a plataforma em suas tarefas.
E se você quiser se aprofundar no tema de implementação de IA – assine o canal do Telegram "Дело в промпте" (O negócio no prompt). Compartilhamos lá o que não cabe nos artigos: casos, resultados de implementações, guias e prompts prontos.





