Não incorpore IA em todos os sistemas corporativos, é um erro de arquitetura
Integrar IA diretamente em cada sistema corporativo cria silos e dificulta o gerenciamento. Em vez disso, a IA deve ser uma camada separada, acessível a todos os sistemas, mas pertencente a nenhum. Este artigo explora essa abordagem, seus benefícios e os desafios de implementação, incluindo segurança e governança.
MundiX News·25 de maio de 2026·15 min de leitura·👁 4 views
Olá, Habr. Muitos me conhecem por Dobrodel, DIT de Moscou e Monq, mas este artigo não é sobre biografia. É sobre a bifurcação arquitetônica em que quase todos os fornecedores de software corporativo se encontrarão agora. Passei muitos anos em grandes circuitos de TI corporativos. Lembro-me da época em que o CSS em um site já parecia uma inovação. Portanto, vejo o hype atual em torno do LLM não como uma disputa sobre "qual modelo é melhor - Gemini ou Claude", mas como o início de uma nova classe de software corporativo.
A principal ideia deste artigo é simples: não incorpore IA em todos os sistemas corporativos como um circuito de IA separado e independente. O usuário deve ver a IA onde trabalha: em CRM, ECM, ITSM, monitoramento, portal ou chat corporativo. Mas os processos de IA, modelos, GPUs, gateway, limites, auditoria, políticas de acesso e responsabilidade devem residir em uma camada corporativa separada.
A IA deve estar acessível a partir de todos os sistemas corporativos, mas não deve pertencer a nenhum deles.
Assim como um contador trabalha no 1C, no e-mail e no portal corporativo, a IA corporativa também deve ser capaz de trabalhar com diferentes sistemas, sem se transformar em um módulo de um deles.
A maneira mais fácil de ver o absurdo do AI Inside é olhar não para a interface, mas para a infraestrutura. A empresa não comprará um servidor GPU separado para ERP, um servidor GPU separado para CRM, um servidor GPU separado para ECM, um servidor GPU separado para ITSM e um servidor GPU separado para monitoramento. O modelo também não deve viver separadamente em cada sistema. Se o GPU é compartilhado, os modelos são compartilhados, o gateway é compartilhado, os limites são compartilhados e a auditoria é compartilhada, então a IA corporativa já se tornou uma camada separada. Aqui, nem estou falando sobre conhecimento ainda. Resta reconhecer isso arquitetonicamente.
Como quase incorporamos IA no Monq
Eu e minha equipe estamos desenvolvendo o Monq, este produto já atende mais de 5 milhões de objetos de infraestrutura de TI em mais de 50 organizações. O produto é simplesmente feito para ser conectado à IA. Já no início do ano passado, tínhamos uma solução de produto muito simples sobre a mesa: incorporar o LLM no Monq e criar um copiloto de engenheiro. Fazer uma análise inteligente de incidentes, RCA inteligente, anexar correlações inteligentes, adicionar um chat na documentação, ensinar o sistema a escrever postmortems, analisar incidentes e chamar isso de sistema AIOps de nova geração. Então, é claro, mostrar uma bela demonstração em uma conferência.
Honestamente: isso seria lógico. E, muito provavelmente, seria vendido. Quando você constrói um produto empresarial por muitos anos, é muito difícil resistir à tentação de dizer: "bem, agora também adicionaremos IA ao nosso produto". Além disso, o mercado ao redor já se parece com uma guirlanda de copilotos: cada sistema tem seu próprio "assistente inteligente", cada fornecedor tem seu próprio AI inside, cada botão tem seu pequeno profeta.
Mas quantos deles você realmente usa?
Mas quanto mais discutíamos isso, mais claro se tornava: se simplesmente incorporarmos IA no Monq, faremos um belo recurso - e perderemos o principal.
Não apenas a teoria nos levou a essa ideia. Já estamos vendo como grandes clientes usam a IA perto do Monq: no varejo, banco e empresa de manufatura. Arquitetonicamente, os cenários são semelhantes: a IA é implantada como um circuito corporativo separado, obtém acesso aos dados necessários por meio de interfaces gerenciadas, pega o contexto do incidente, observa eventos, alterações, documentos ou histórico relacionados, analisa tudo isso e retorna o resultado de volta ao fluxo de trabalho - para o cartão de incidente, comentário, rascunho de análise ou dica para o engenheiro.
Ou seja, a IA se comporta não como um módulo do sistema de monitoramento, mas como um novo participante do processo. Quase como uma pessoa: entrou no sistema, olhou o incidente, abriu os dados relacionados, comparou os fatos, tirou uma conclusão e fez uma anotação. Apenas mais rápido, mais estável e melhor em digerir um grande volume de contexto.
Para nós, isso se tornou um sinal importante. Se a IA ainda funciona em vários sistemas, é estranho costurar todo esse circuito dentro de um produto. O produto deve dar à IA uma interface gerenciada normal. Mas a própria IA corporativa deve pertencer à empresa, e não a um produto ou sistema de monitoramento separado.
E aqui me peguei em um pensamento desagradável. O mercado agora incentiva uma solução simples: adicionar uma camada de IA dentro do produto, dar um belo nome, mostrar em uma conferência e obter comentários entusiasmados. Mas, em um ano, o cliente terá dez desses assistentes e ninguém entenderá quem vai para onde, o que registra, qual modelo chama e onde está a fronteira da responsabilidade.
Se cada sistema corporativo começar a dar à luz seu próprio pequeno copiloto, não obteremos transformação, mas um novo zoológico corporativo:
copiloto em monitoramento;
copiloto em gerenciamento de documentos;
copiloto em vendas;
copiloto no Service Desk;
RAG no joelho de advogados;
bot em compras;
agentes pessoais para funcionários fortes;
circular proibitivo do departamento de segurança da informação.
E nenhuma resposta comum para as perguntas: quem tem acesso aos dados, o que é registrado, qual modelo é chamado, quanto custa, onde uma pessoa deve confirmar a ação e quem é responsável pelo erro.
O incidente de IA mais assustador não começa com uma alucinação do modelo, mas com a frase: "quem deu a ele acesso a esta pasta?"
Uma coisa simples:
Assistente - responde. Agente - faz. Isso é claro para todos. Mas quem está rastreando e gerenciando tudo isso? - Camada operacional.
Se uma empresa tem um assistente, é uma experiência.
Se dez agentes, já é um novo sistema de produção.
Se cem agentes sem gerenciamento comum, não é uma transformação digital, mas uma oficina onde todos receberam uma ferramenta, mas esqueceram as regras de segurança.
Essencialmente, a IA corporativa está se tornando uma terceira camada entre pessoas e sistemas de informação. Por um lado, é semelhante a uma pessoa: lê documentos, procura informações, compara versões, classifica solicitações, explica incidentes e sugere ações. Por outro lado, permanece um executor de máquina: precisa de direitos de acesso, contexto, ferramentas, limites, logs, testes, regras de parada e um proprietário de responsabilidade. Portanto, este não é mais um botão. Este é um novo participante no processo corporativo.
Monq nos ensinou a não confundir ferramenta e camada de gerenciamento
Monq não apareceu porque o mundo precisava de mais um monitoramento. Havia muitos monitoramentos. E temos um artigo sobre isso no Habr.
Zabbix viu uma coisa. Prometheus - outra. APM - terceiro. Service Desk - quarto. Os logs viviam separados. Os sistemas de rede separados. Tabelas e regulamentos manuais separados. E o chefe de operações ainda perguntava: "então, o que temos com o serviço?"
Quando há muitas ferramentas, o mercado precisa não de mais uma ferramenta, mas de uma camada de gerenciamento sobre elas.
Em grandes implementações do Monq, já passamos por uma história semelhante: dezenas de sistemas externos, milhões de unidades de configuração, centenas de cenários de automação, milhões de métricas e eventos por dia. O valor não estava em substituir tudo de uma vez, mas em reunir a paisagem de TI dispersa em uma imagem gerenciável da saúde de objetos de negócios reais sob um único guarda-chuva.
A mesma coisa está acontecendo com a IA agora. Há muitos modelos. Há muitos chats. Haverá ainda mais agentes. Mas muitos modelos não significam IA corporativa, assim como muitos monitoramentos não significam gerenciamento.
Em algum momento, fui finalmente atingido não por uma questão técnica, mas por um cenário de cliente simples: "bom, o Monq poderá explicar o incidente. E este mesmo assistente poderá ver as alterações no ITSM, o contrato no ECM para o fornecimento de novos servidores, a solicitação no 1C e a ata da última reunião?"
Eu realmente gosto da comparação que trago nas reuniões. Imagine que você está gerenciando uma grande empresa de construção. Você tem centenas de máquinas nas quais já investiu bilhões de rublos. Você pode incorporar um módulo não tripulado em cada escavadeira. Ou você pode criar um operador que possa sentar-se em máquinas diferentes e trabalhar com a interface existente.
Imagine, para a escavadeira, seu próprio módulo de controle, para a carregadeira, seu próprio, para o caminhão, seu próprio, ou é mais fácil criar um robô antropomórfico com habilidades para controlar cada máquina? Na robótica, uma lógica semelhante também é visível: às vezes é mais fácil ensinar um novo executor a trabalhar com a infraestrutura existente do que refazer toda a infraestrutura para cada novo mecanismo.
Os negócios precisam não de modelos, mas de implementações
O mercado agora tem uma estranha distorção de percepção. Parece que a principal questão da IA corporativa soa assim: "qual modelo é melhor?"
Esta é uma questão importante, mas certamente não a primeira.
Modelos fortes são criticamente importantes. Sem eles, todo o resto não faz sentido. Mas um modelo ainda não é uma implementação.
Um modelo é um motor. Sem um motor, o carro não vai andar. Mas se você está construindo uma frota de carros, você também precisa de despacho, rotas, aprovações, manutenção, controle de combustível, logs, responsabilidade e regras sobre quem tem o direito de ir para onde.
Com o LLM, a mesma coisa. Você pode pegar um bom modelo. Você pode implantar um local. Você pode comprar acesso à API. Você pode levantar o RAG nos documentos. Você pode montar um cenário de agente no n8n, Dify, LangChain ou seu código Python.
Para a primeira verificação da hipótese, isso é normal.
Mas assim que o protótipo começa a viver mais do que a apresentação, surgem questões que o modelo em si não resolve:
quem tem acesso a quais documentos;
se esses dados podem ser transferidos para um modelo específico;
onde está o log de solicitações, respostas, fontes e ações;
como limitar o custo de tokens e tempo de GPU;
onde uma pessoa deve confirmar a ação;
quem é responsável pelo erro;
como transferir um cenário bem-sucedido de um departamento para outro.
Em algum momento, "vamos apenas conectar uma rede neural" se transforma em "onde está nosso log de ações da última sexta-feira?"
É aqui que começa a IA corporativa. Não onde apareceu o primeiro belo botão de rede neural, mas onde a empresa enfrentou acesso, responsabilidade, custo, auditoria e escalonamento.
Por que um agente de IA é mais complicado do que uma integração normal
Sim, algumas tarefas são semelhantes a ESB, BPM, iPaaS, MDM ou ITSM. Mas a camada de IA gerencia não apenas integrações. Ele gerencia executores probabilísticos: modelos, contexto, agentes, ferramentas, fontes, validação humana e custo de inferência.
Uma integração normal geralmente faz o que lhe é dito. Um agente de IA primeiro "entende" o que lhe foi dito, então decide qual ferramenta chamar e, em seguida, explica com confiança por que era necessário fazer isso. Isso é poderoso. E é por isso que é perigoso.
Um agente de IA corporativo tem seu próprio modelo de ameaças: prompt injection por meio de documentos, vazamento de dados por meio do contexto, chamadas incorretas de ferramentas, acesso não autorizado a fontes, execução de ações sem confirmação, envenenamento da base de conhecimento, citação incorreta de fontes e aumento de custo devido a ciclos de agente (tenho certeza de que você está familiarizado com esses casos).
O modelo pode ser probabilístico, mas o circuito ao redor dele deve ser o mais determinístico possível: quem tem acesso, quais fontes são permitidas, quais ferramentas podem ser chamadas, quais ações exigem confirmação, onde está o log e como reproduzir a cadeia de tomada de decisão. É este circuito determinístico em torno do núcleo probabilístico que distingue um cenário de IA industrial de uma bela demonstração.
Na produção, não basta dizer "na demonstração responde bem". Precisamos de conjuntos confiáveis: perguntas típicas, perguntas ruins, documentos desatualizados, fontes conflitantes, verificações de falha, verificações de acesso, verificações de citabilidade e testes de regressão após alterar o modelo, prompt ou índice.
Antes de conectar o agente aos dados, você precisa entender as classes de dados: públicos, internos, confidenciais, pessoais, segredo comercial, CII ou circuito de modo. O mesmo agente não deve funcionar da mesma forma com as instruções para os funcionários e com o documento que não pode ser retirado do perímetro.
O princípio do menor privilégio deve ser aplicado não apenas a pessoas e contas de serviço, mas também a agentes: o agente recebe um conjunto mínimo de dados e ações para um cenário específico, e não "acesso a tudo, porque ele é inteligente". O agente deve ter não apenas direitos sobre os dados, mas também direitos sobre as ações: ler, criar um rascunho, alterar, executar um runbook, enviar, excluir. E esses direitos não devem ser uma única regra booleana agent_enabled=true.
Um tópico separado é a memória. O que o agente lembra? Onde está armazenado? Quem pode excluir a memória? O que entra na próxima solicitação? Como distinguir o contexto de trabalho da auditoria? Como não misturar o contexto de diferentes clientes, funções ou unidades? Sem respostas para essas perguntas, o "assistente inteligente" rapidamente se torna uma fonte de vazamentos implícitos.
E mais uma coisa, próxima a mim no Monq: os agentes de IA também precisam de observabilidade. Latência, custo, erros de chamada, taxa de falha, reclamações sobre alucinações, qualidade da resposta, cobertura de conjuntos de avaliação, desvio após atualizar o modelo ou índice - todos esses são os mesmos sinais operacionais que as métricas de serviço. Os conjuntos de avaliação são cenários de teste para qualidade e segurança: perguntas típicas, perguntas ruins, documentos conflitantes, verificações de falha, verificações de direitos de acesso e correção de links para fontes.
A IA sombria já está dentro das empresas
Há mais uma coisa desagradável. A IA corporativa já foi implementada em muitas de suas organizações. Só que muitas vezes não é implementada por ordem, por projeto, não por meio de TI e não por meio do departamento de segurança. É implementada por meio dos telefones pessoais dos funcionários, laptops domésticos, serviços externos e contas pessoais.
As pessoas usam a IA porque ela oferece produtividade pessoal. Uma pessoa viu uma vez que em dez minutos você pode fazer o que antes levava duas horas, e ela não quer voltar atrás.
Você pode escrever uma proibição. Você pode fechar o acesso a serviços externos de máquinas de trabalho. Você pode realizar um briefing. Tudo isso é necessário, mas não resolve o problema completamente. O funcionário ainda tem um telefone, uma conta pessoal e um prazo para amanhã de manhã. Mesmo em uma instalação de modo. Há muitos exemplos: um funcionário fotografa um documento interno em seu telefone pessoal, o telefone sincroniza a foto com a nuvem e a pessoa nem considera isso um incidente de segurança da informação.
A proibição sem uma alternativa conveniente não cria segurança, mas IA sombria.
Para indústrias regulamentadas, isso é especialmente doloroso. Dados pessoais, segredos comerciais, segredos bancários, documentos de modo, CII, políticas internas de segurança da informação, 152-FZ e outras restrições não desaparecem apenas porque o modelo é "muito inteligente".
É importante ser preciso: 152-FZ em si não diz "mantenha o LLM apenas on-prem". 242-FZ sobre a localização de bancos de dados de dados pessoais de cidadãos russos também não transforma cada cenário de IA em um projeto on-prem obrigatório. Mas juntos, esses requisitos forçam o operador a entender quais dados são processados, onde são armazenados, para quem são transferidos, quem tem acesso e quais medidas de proteção são aplicadas.
E agora tente responder honestamente a essas perguntas, se um funcionário enviou um pedaço de contrato ou protocolo para um chat externo, o que acontece com ele a seguir?
Portanto, a questão não é mais se a IA aparecerá na indústria, bancos, setor público, complexo militar-industrial, medicina, serviços jurídicos, suporte e operações de TI. Já apareceu.
A questão é outra: será sombria ou gerenciada?
Um circuito fechado não é "um servidor com um chat"
Nas vendas corporativas russas, há uma frase que às vezes é pronunciada como um feitiço: "precisa estar em um circuito fechado".
Parte do mercado é cética em relação a isso: eles estão complicando tudo de novo, você não pode simplesmente pegar a nuvem de novo, os seguranças estão retardando o progresso de novo. Eu entendo essa irritação. Mas em circuitos grandes reais, um circuito fechado muitas vezes não é um capricho, mas um modelo normal de risco e ameaças.
Se você trabalha com materiais judiciais, documentos médicos, dados bancários, solicitações de cidadãos, compras, documentação técnica, regulamentos industriais ou segredos comerciais, a questão "posso enviar isso para um serviço externo?" deixa de ser filosófica.
Muitas vezes a resposta é: não.
Mas um circuito fechado não é "compramos um servidor com GPU e instalamos um chat".
São quatro camadas:
computação;
modelos;
camada operacional;
pessoas e processos.
Sem o primeiro, não há nada para calcular. Sem o segundo, não há nada para pensar. Sem o terceiro, não há ninguém para gerenciar. Sem o quarto, ninguém usará.
GPU sem filas, limites e proprietários não é infraestrutura, mas uma maneira muito cara de aquecer o ar.
Para grandes organizações, a questão não se resume a "nuvem ou on-prem". Precisamos de um modelo de implantação para a classe de dados: o que permanece dentro do perímetro, o que pode passar pelo gateway, quais modelos são permitidos, onde os embeddings são armazenados, quem gerencia as chaves, como os logs entram no circuito de segurança da informação e como o cenário é desativado em caso de incidente.
Em um circuito grande, a camada operacional de IA não pode viver separadamente da segurança da informação: identificação, funções, logs, segredos, integração com SIEM/SOC, segmentação de circuitos, controle de ações e um modelo de desativação devem ser projetados imediatamente, e não "após um piloto bem-sucedido".
A coisa mais difícil, aliás, quase sempre não é o hardware e nem o modelo. A coisa mais difícil são as pessoas. Não no sentido de "elas estão retardando". Mas no sentido de que um bom piloto de IA muda o comportamento da organização. As pessoas param de procurar manualmente. Param de copiar pedaços de documentos antigos. Param de lembrar de memória o que pode ser extraído com segurança do contexto. Param de tolerar a rotina, se viram uma vez que pode ser mais rápido.
O principal problema não é o lançamento, mas o escalonamento
O MVP hoje é montado rapidamente. Às vezes até rápido demais.
Um engenheiro forte e um cliente de negócios podem mostrar um cenário de trabalho em algumas semanas: pesquisa por regulamentos, rascunho de resposta, ata de reunião, verificação de documentos, análise de tickets, classificação de solicitações.
Na demonstração, tudo parece convincente.
Mas então começa a parte adulta:
os dados precisam ser atualizados regularmente;
os direitos de acesso precisam ser extraídos de sistemas corporativos reais;
a qualidade precisa ser medida não em três belos exemplos, mas em centenas de operações;
o resultado precisa ser incorporado ao local de trabalho do funcionário;
o departamento de segurança da informação deve entender o modelo de ameaças;
os negócios devem ver a economia;
o departamento de TI deve entender a operação;
o proprietário do processo deve estar pronto para alterar o regulamento.
É por isso que no CIPR-2026 já se falava abertamente: o problema dos negócios não é o lançamento de pilotos de IA, mas o escalonamento.
As estatísticas mundiais dizem o mesmo. No McKinsey State of AI 2025, quase nove em cada dez entrevistados dizem que suas organizações usam IA regularmente, mas a transição de pilotos para um impacto em larga escala nos negócios permanece incompleta para a maioria. O efeito é obtido não por aqueles que simplesmente conectaram o modelo, mas por aqueles que estão reconstruindo os processos, introduzindo regras, métricas, treinamento, verificação humana e incluindo a responsabilidade dos gerentes.
Para mim, o piloto termina não quando a demonstração agradou ao gerente, mas quando há um proprietário do processo, um conjunto de testes, métricas de qualidade, regras de acesso, um log de ações, a economia da operação e uma decisão: escalonamos, finalizamos ou fechamos.
A economia de um cenário de IA deve ser calculada não como "o custo da plataforma versus o salário do funcionário", mas o custo da operação antes/depois: tempo da pessoa, custo do modelo ou GPU, proporção de verificação manual, porcentagem de erros, custo do incidente e custo de suporte.
Um agente economiza horas. Cem agentes sem gerenciamento economizam seu sono. Mas o benefício da IA começa em escala. A escala sem uma camada operacional se transforma em caos.
O que é Unica AI tecnicamente
Se simplificarmos, Unica AI não é LLM e nem "chat com documentos". É uma camada de execução e gerenciamento de cenários de IA corporativos: entre pessoas, aplicativos de negócios, conhecimento, agentes, modelos e regras de segurança.
O primeiro circuito são as interfaces. Tem dois lados. O primeiro é uma interface para uma pessoa: um local de trabalho onde um funcionário se comunica com assistentes e agentes, faz perguntas, executa cenários, recebe respostas, rascunhos, protocolos, dados extraídos, tarefas e links para fontes. O segundo é uma interface para aplicativos de negócios: API, eventos, conectores, filas, webhooks, ferramentas MCP. Por meio dele, a camada de IA se conecta ao 1C, ECM, ERP, CRM, ITSM, Monq, BI, telefonia e portais internos. O objetivo não é incorporar IA separada em cada sistema, mas dar a todos os sistemas acesso a uma única camada de IA gerenciada.
O segundo circuito é o conhecimento. Aqui vivem o armazenamento markdown, o armazenamento de arquivos e o circuito RAG. O Markdown é conveniente para memória estruturada: instruções, regulamentos, prompts, cartões de cenário, notas de agentes. O armazenamento de arquivos é necessário para PDF, DOCX, XLSX, apresentações, digitalizações, áudio, anexos e artefatos de trabalho. E RAG já não é "uma pasta com arquivos", mas um pipeline: aceitar um documento, analisá-lo, dividi-lo em chunks, construir embeddings, vincular à fonte, atualizar, excluir, versionar e levar em conta os direitos de acesso. Simplificando: arquivos e markdown são memória e matéria-prima, RAG é uma maneira de extrair com segurança o contexto necessário dessa memória. Para os assistentes, o RAG é crítico, porque eles devem responder com fontes. Para os agentes, os arquivos de trabalho também são importantes como o estado da tarefa, resultados intermediários e memória gerenciada do cenário.
O terceiro circuito é o agente runtime: workflow, regras do agente executor básico, tools, skills, MCP, instruções do sistema, prompts, lógica de aprovação e ciclo de vida dos cenários. O assistente geralmente responde: encontrou, explicou, referiu-se à fonte. O agente faz: classifica a solicitação, verifica o conjunto de documentos, compara as versões do contrato, prepara um rascunho, cria uma tarefa, chama a ferramenta permitida, executa o workflow. E aqui o agente já não deve ser "um script com fantasia". Ele deve ter direitos, restrições, um proprietário, um log de ações, sandbox/dry-run, regras de parada e um ciclo de vida: draft → test → pilot → production → disabled → archived.
O quarto circuito são modelos e AI Gateway. Na IA corporativa, quase nunca haverá um modelo para tudo. Um LLM é mais adequado para respostas rápidas, outro para análise de documentos, um terceiro para código, OCR, ASR, TTS, embeddings, rerankers, modelos on-prem locais e, às vezes, APIs externas são necessários separadamente. O AI Gateway é necessário como um único ponto de gerenciamento: roteamento, prioridades, fallback, chaves, limites, tokens, faturamento, cotas por usuários e cenários, modelos permitidos para diferentes classes de dados. Esta é a camada que responde a perguntas desagradáveis, mas importantes: qual modelo foi chamado, por que ele, quanto custou, era possível enviar esses dados para lá e quem queimou o orçamento.
O quinto circuito é segurança e operação. Aqui vivem usuários, funções, direitos, espaços, políticas de acesso, auditoria, um log de solicitações e ações, monitoramento de segurança, monitoramento de desempenho, análise de uso, conjuntos de avaliação, controle de qualidade, alertas, análise de incidentes e "pulso de implementação": quem realmente usa o sistema, quais cenários decolaram, onde o custo está crescendo, onde a qualidade está caindo, quais assistentes precisam ser finalizados ou desativados. Sem isso, a IA corporativa permanece uma bela demonstração que todos elogiam, mas ninguém ousa colocar em operação industrial.
Importante: tudo isso pode ser montado em open source. Um bom exemplo é o artigo Sminex sobre uma plataforma LLM corporativa: Open WebUI como uma única janela para os funcionários, LiteLLM como AI Gateway, Langflow e MCP para cenários e ferramentas, vLLM/Ollama para inferência, RAGFlow e seus próprios RAG-pipeline para conhecimento, Prometheus/Grafana e Langfuse para observabilidade. Sua principal conclusão é próxima a mim: o open source acelera o início, mas a dor se manifesta nas junções - versões, compatibilidade, auth, atualizações, depuração, limites, observabilidade e operação.
Mas se você montar tudo isso sozinho, você está realmente começando a construir um produto de IA interno. Ele precisa ser projetado, atualizado, protegido, monitorado, documentado, treinar usuários e dar suporte nas junções. E nos circuitos empresariais russos, questões legais com licenças, responsabilidade pelo trabalho e suporte, riscos de sanções, repositórios fechados, requisitos de segurança da informação, 152-FZ, registro de software, independência de importação e muito mais são adicionados. Portanto, o open source é uma ótima maneira de provar a arquitetura. Mas um circuito industrial precisa de uma camada operacional montada, verificada e suportada, de preferência com um fornecedor do outro lado do fio que o ajudará a reduzir os riscos.
Esquematicamente, fica assim:
Neste esquema, o Monq não perde o papel. Pelo contrário, torna-se uma das fontes mais importantes de contexto operacional para o tratamento de incidentes e um meio de controle e observabilidade da plataforma de IA. Mas a IA permanece uma classe separada, porque gerencia não apenas incidentes, mas o trabalho digital da empresa.
O mesmo padrão surge em um banco, varejo ou setor público. Não basta o agente "responder com base no conhecimento". Ele precisa verificar os documentos, acessar vários sistemas, levar em conta a função do usuário, não mostrar o supérfluo, referir-se à fonte, solicitar confirmação antes da ação e deixar um log.
Isso já não é um chat. É um processo gerenciado.
Por que decidimos que o circuito básico deve ser aberto
O Monq tem uma versão gratuita. Ajudou o mercado a tocar o produto, mas a gratuidade em si não faz um padrão. Com o Unica AI, decidimos ir mais longe.
O circuito básico deve ser aberto, porque a camada que funciona com dados corporativos, modelos, agentes e auditoria não deve ser uma caixa preta. Qualquer coisa pode cair de tal caixa: um vazamento de chaves, uma chamada estranha para um modelo externo, um prompt inseguro ou uma dependência que ninguém verificou.
O problema de tal caixa preta é resolvido por um alto nível de
Olá, Habr. Muitos me conhecem por Dobrodel, DIT de Moscou e Monq, mas este artigo não é sobre biografia. É sobre a bifurcação arquitetônica em que quase todos os fornecedores de software corporativo se encontrarão agora. Passei muitos anos em grandes circuitos de TI corporativos. Lembro-me da época em que o CSS em um site já parecia uma inovação. Portanto, vejo o hype atual em torno do LLM não como uma disputa sobre "qual modelo é melhor - Gemini ou Claude", mas como o início de uma nova classe de software corporativo.
A principal ideia deste artigo é simples: não incorpore IA em todos os sistemas corporativos como um circuito de IA separado e independente. O usuário deve ver a IA onde trabalha: em CRM, ECM, ITSM, monitoramento, portal ou chat corporativo. Mas os processos de IA, modelos, GPUs, gateway, limites, auditoria, políticas de acesso e responsabilidade devem residir em uma camada corporativa separada.
A IA deve estar acessível a partir de todos os sistemas corporativos, mas não deve pertencer a nenhum deles.
Assim como um contador trabalha no 1C, no e-mail e no portal corporativo, a IA corporativa também deve ser capaz de trabalhar com diferentes sistemas, sem se transformar em um módulo de um deles.
A maneira mais fácil de ver o absurdo do AI Inside é olhar não para a interface, mas para a infraestrutura. A empresa não comprará um servidor GPU separado para ERP, um servidor GPU separado para CRM, um servidor GPU separado para ECM, um servidor GPU separado para ITSM e um servidor GPU separado para monitoramento. O modelo também não deve viver separadamente em cada sistema. Se o GPU é compartilhado, os modelos são compartilhados, o gateway é compartilhado, os limites são compartilhados e a auditoria é compartilhada, então a IA corporativa já se tornou uma camada separada. Aqui, nem estou falando sobre conhecimento ainda. Resta reconhecer isso arquitetonicamente.
Como quase incorporamos IA no Monq
Eu e minha equipe estamos desenvolvendo o Monq, este produto já atende mais de 5 milhões de objetos de infraestrutura de TI em mais de 50 organizações. O produto é simplesmente feito para ser conectado à IA. Já no início do ano passado, tínhamos uma solução de produto muito simples sobre a mesa: incorporar o LLM no Monq e criar um copiloto de engenheiro. Fazer uma análise inteligente de incidentes, RCA inteligente, anexar correlações inteligentes, adicionar um chat na documentação, ensinar o sistema a escrever postmortems, analisar incidentes e chamar isso de sistema AIOps de nova geração. Então, é claro, mostrar uma bela demonstração em uma conferência.
Honestamente: isso seria lógico. E, muito provavelmente, seria vendido. Quando você constrói um produto empresarial por muitos anos, é muito difícil resistir à tentação de dizer: "bem, agora também adicionaremos IA ao nosso produto". Além disso, o mercado ao redor já se parece com uma guirlanda de copilotos: cada sistema tem seu próprio "assistente inteligente", cada fornecedor tem seu próprio AI inside, cada botão tem seu pequeno profeta.
Mas quantos deles você realmente usa?
Mas quanto mais discutíamos isso, mais claro se tornava: se simplesmente incorporarmos IA no Monq, faremos um belo recurso - e perderemos o principal.
Não apenas a teoria nos levou a essa ideia. Já estamos vendo como grandes clientes usam a IA perto do Monq: no varejo, banco e empresa de manufatura. Arquitetonicamente, os cenários são semelhantes: a IA é implantada como um circuito corporativo separado, obtém acesso aos dados necessários por meio de interfaces gerenciadas, pega o contexto do incidente, observa eventos, alterações, documentos ou histórico relacionados, analisa tudo isso e retorna o resultado de volta ao fluxo de trabalho - para o cartão de incidente, comentário, rascunho de análise ou dica para o engenheiro.
Ou seja, a IA se comporta não como um módulo do sistema de monitoramento, mas como um novo participante do processo. Quase como uma pessoa: entrou no sistema, olhou o incidente, abriu os dados relacionados, comparou os fatos, tirou uma conclusão e fez uma anotação. Apenas mais rápido, mais estável e melhor em digerir um grande volume de contexto.
Para nós, isso se tornou um sinal importante. Se a IA ainda funciona em vários sistemas, é estranho costurar todo esse circuito dentro de um produto. O produto deve dar à IA uma interface gerenciada normal. Mas a própria IA corporativa deve pertencer à empresa, e não a um produto ou sistema de monitoramento separado.
E aqui me peguei em um pensamento desagradável. O mercado agora incentiva uma solução simples: adicionar uma camada de IA dentro do produto, dar um belo nome, mostrar em uma conferência e obter comentários entusiasmados. Mas, em um ano, o cliente terá dez desses assistentes e ninguém entenderá quem vai para onde, o que registra, qual modelo chama e onde está a fronteira da responsabilidade.
Se cada sistema corporativo começar a dar à luz seu próprio pequeno copiloto, não obteremos transformação, mas um novo zoológico corporativo:
copiloto em monitoramento;
copiloto em gerenciamento de documentos;
copiloto em vendas;
copiloto no Service Desk;
RAG no joelho de advogados;
bot em compras;
agentes pessoais para funcionários fortes;
circular proibitivo do departamento de segurança da informação.
E nenhuma resposta comum para as perguntas: quem tem acesso aos dados, o que é registrado, qual modelo é chamado, quanto custa, onde uma pessoa deve confirmar a ação e quem é responsável pelo erro.
O incidente de IA mais assustador não começa com uma alucinação do modelo, mas com a frase: "quem deu a ele acesso a esta pasta?"
Uma coisa simples:
Assistente - responde. Agente - faz. Isso é claro para todos. Mas quem está rastreando e gerenciando tudo isso? - Camada operacional.
Se uma empresa tem um assistente, é uma experiência.
Se dez agentes, já é um novo sistema de produção.
Se cem agentes sem gerenciamento comum, não é uma transformação digital, mas uma oficina onde todos receberam uma ferramenta, mas esqueceram as regras de segurança.
Essencialmente, a IA corporativa está se tornando uma terceira camada entre pessoas e sistemas de informação. Por um lado, é semelhante a uma pessoa: lê documentos, procura informações, compara versões, classifica solicitações, explica incidentes e sugere ações. Por outro lado, permanece um executor de máquina: precisa de direitos de acesso, contexto, ferramentas, limites, logs, testes, regras de parada e um proprietário de responsabilidade. Portanto, este não é mais um botão. Este é um novo participante no processo corporativo.
Monq nos ensinou a não confundir ferramenta e camada de gerenciamento
Monq não apareceu porque o mundo precisava de mais um monitoramento. Havia muitos monitoramentos. E temos um artigo sobre isso no Habr.
Zabbix viu uma coisa. Prometheus - outra. APM - terceiro. Service Desk - quarto. Os logs viviam separados. Os sistemas de rede separados. Tabelas e regulamentos manuais separados. E o chefe de operações ainda perguntava: "então, o que temos com o serviço?"
Quando há muitas ferramentas, o mercado precisa não de mais uma ferramenta, mas de uma camada de gerenciamento sobre elas.
Em grandes implementações do Monq, já passamos por uma história semelhante: dezenas de sistemas externos, milhões de unidades de configuração, centenas de cenários de automação, milhões de métricas e eventos por dia. O valor não estava em substituir tudo de uma vez, mas em reunir a paisagem de TI dispersa em uma imagem gerenciável da saúde de objetos de negócios reais sob um único guarda-chuva.
A mesma coisa está acontecendo com a IA agora. Há muitos modelos. Há muitos chats. Haverá ainda mais agentes. Mas muitos modelos não significam IA corporativa, assim como muitos monitoramentos não significam gerenciamento.
Em algum momento, fui finalmente atingido não por uma questão técnica, mas por um cenário de cliente simples: "bom, o Monq poderá explicar o incidente. E este mesmo assistente poderá ver as alterações no ITSM, o contrato no ECM para o fornecimento de novos servidores, a solicitação no 1C e a ata da última reunião?"
Eu realmente gosto da comparação que trago nas reuniões. Imagine que você está gerenciando uma grande empresa de construção. Você tem centenas de máquinas nas quais já investiu bilhões de rublos. Você pode incorporar um módulo não tripulado em cada escavadeira. Ou você pode criar um operador que possa sentar-se em máquinas diferentes e trabalhar com a interface existente.
Imagine, para a escavadeira, seu próprio módulo de controle, para a carregadeira, seu próprio, para o caminhão, seu próprio, ou é mais fácil criar um robô antropomórfico com habilidades para controlar cada máquina? Na robótica, uma lógica semelhante também é visível: às vezes é mais fácil ensinar um novo executor a trabalhar com a infraestrutura existente do que refazer toda a infraestrutura para cada novo mecanismo.
Os negócios precisam não de modelos, mas de implementações
O mercado agora tem uma estranha distorção de percepção. Parece que a principal questão da IA corporativa soa assim: "qual modelo é melhor?"
Esta é uma questão importante, mas certamente não a primeira.
Modelos fortes são criticamente importantes. Sem eles, todo o resto não faz sentido. Mas um modelo ainda não é uma implementação.
Um modelo é um motor. Sem um motor, o carro não vai andar. Mas se você está construindo uma frota de carros, você também precisa de despacho, rotas, aprovações, manutenção, controle de combustível, logs, responsabilidade e regras sobre quem tem o direito de ir para onde.
Com o LLM, a mesma coisa. Você pode pegar um bom modelo. Você pode implantar um local. Você pode comprar acesso à API. Você pode levantar o RAG nos documentos. Você pode montar um cenário de agente no n8n, Dify, LangChain ou seu código Python.
Para a primeira verificação da hipótese, isso é normal.
Mas assim que o protótipo começa a viver mais do que a apresentação, surgem questões que o modelo em si não resolve:
quem tem acesso a quais documentos;
se esses dados podem ser transferidos para um modelo específico;
onde está o log de solicitações, respostas, fontes e ações;
como limitar o custo de tokens e tempo de GPU;
onde uma pessoa deve confirmar a ação;
quem é responsável pelo erro;
como transferir um cenário bem-sucedido de um departamento para outro.
Em algum momento, "vamos apenas conectar uma rede neural" se transforma em "onde está nosso log de ações da última sexta-feira?"
É aqui que começa a IA corporativa. Não onde apareceu o primeiro belo botão de rede neural, mas onde a empresa enfrentou acesso, responsabilidade, custo, auditoria e escalonamento.
Por que um agente de IA é mais complicado do que uma integração normal
Sim, algumas tarefas são semelhantes a ESB, BPM, iPaaS, MDM ou ITSM. Mas a camada de IA gerencia não apenas integrações. Ele gerencia executores probabilísticos: modelos, contexto, agentes, ferramentas, fontes, validação humana e custo de inferência.
Uma integração normal geralmente faz o que lhe é dito. Um agente de IA primeiro "entende" o que lhe foi dito, então decide qual ferramenta chamar e, em seguida, explica com confiança por que era necessário fazer isso. Isso é poderoso. E é por isso que é perigoso.
Um agente de IA corporativo tem seu próprio modelo de ameaças: prompt injection por meio de documentos, vazamento de dados por meio do contexto, chamadas incorretas de ferramentas, acesso não autorizado a fontes, execução de ações sem confirmação, envenenamento da base de conhecimento, citação incorreta de fontes e aumento de custo devido a ciclos de agente (tenho certeza de que você está familiarizado com esses casos).
O modelo pode ser probabilístico, mas o circuito ao redor dele deve ser o mais determinístico possível: quem tem acesso, quais fontes são permitidas, quais ferramentas podem ser chamadas, quais ações exigem confirmação, onde está o log e como reproduzir a cadeia de tomada de decisão. É este circuito determinístico em torno do núcleo probabilístico que distingue um cenário de IA industrial de uma bela demonstração.
Na produção, não basta dizer "na demonstração responde bem". Precisamos de conjuntos confiáveis: perguntas típicas, perguntas ruins, documentos desatualizados, fontes conflitantes, verificações de falha, verificações de acesso, verificações de citabilidade e testes de regressão após alterar o modelo, prompt ou índice.
Antes de conectar o agente aos dados, você precisa entender as classes de dados: públicos, internos, confidenciais, pessoais, segredo comercial, CII ou circuito de modo. O mesmo agente não deve funcionar da mesma forma com as instruções para os funcionários e com o documento que não pode ser retirado do perímetro.
O princípio do menor privilégio deve ser aplicado não apenas a pessoas e contas de serviço, mas também a agentes: o agente recebe um conjunto mínimo de dados e ações para um cenário específico, e não "acesso a tudo, porque ele é inteligente". O agente deve ter não apenas direitos sobre os dados, mas também direitos sobre as ações: ler, criar um rascunho, alterar, executar um runbook, enviar, excluir. E esses direitos não devem ser uma única regra booleana agent_enabled=true.
Um tópico separado é a memória. O que o agente lembra? Onde está armazenado? Quem pode excluir a memória? O que entra na próxima solicitação? Como distinguir o contexto de trabalho da auditoria? Como não misturar o contexto de diferentes clientes, funções ou unidades? Sem respostas para essas perguntas, o "assistente inteligente" rapidamente se torna uma fonte de vazamentos implícitos.
E mais uma coisa, próxima a mim no Monq: os agentes de IA também precisam de observabilidade. Latência, custo, erros de chamada, taxa de falha, reclamações sobre alucinações, qualidade da resposta, cobertura de conjuntos de avaliação, desvio após atualizar o modelo ou índice - todos esses são os mesmos sinais operacionais que as métricas de serviço. Os conjuntos de avaliação são cenários de teste para qualidade e segurança: perguntas típicas, perguntas ruins, documentos conflitantes, verificações de falha, verificações de direitos de acesso e correção de links para fontes.
A IA sombria já está dentro das empresas
Há mais uma coisa desagradável. A IA corporativa já foi implementada em muitas de suas organizações. Só que muitas vezes não é implementada por ordem, por projeto, não por meio de TI e não por meio do departamento de segurança. É implementada por meio dos telefones pessoais dos funcionários, laptops domésticos, serviços externos e contas pessoais.
As pessoas usam a IA porque ela oferece produtividade pessoal. Uma pessoa viu uma vez que em dez minutos você pode fazer o que antes levava duas horas, e ela não quer voltar atrás.
Você pode escrever uma proibição. Você pode fechar o acesso a serviços externos de máquinas de trabalho. Você pode realizar um briefing. Tudo isso é necessário, mas não resolve o problema completamente. O funcionário ainda tem um telefone, uma conta pessoal e um prazo para amanhã de manhã. Mesmo em uma instalação de modo. Há muitos exemplos: um funcionário fotografa um documento interno em seu telefone pessoal, o telefone sincroniza a foto com a nuvem e a pessoa nem considera isso um incidente de segurança da informação.
A proibição sem uma alternativa conveniente não cria segurança, mas IA sombria.
Para indústrias regulamentadas, isso é especialmente doloroso. Dados pessoais, segredos comerciais, segredos bancários, documentos de modo, CII, políticas internas de segurança da informação, 152-FZ e outras restrições não desaparecem apenas porque o modelo é "muito inteligente".
É importante ser preciso: 152-FZ em si não diz "mantenha o LLM apenas on-prem". 242-FZ sobre a localização de bancos de dados de dados pessoais de cidadãos russos também não transforma cada cenário de IA em um projeto on-prem obrigatório. Mas juntos, esses requisitos forçam o operador a entender quais dados são processados, onde são armazenados, para quem são transferidos, quem tem acesso e quais medidas de proteção são aplicadas.
E agora tente responder honestamente a essas perguntas, se um funcionário enviou um pedaço de contrato ou protocolo para um chat externo, o que acontece com ele a seguir?
Portanto, a questão não é mais se a IA aparecerá na indústria, bancos, setor público, complexo militar-industrial, medicina, serviços jurídicos, suporte e operações de TI. Já apareceu.
A questão é outra: será sombria ou gerenciada?
Um circuito fechado não é "um servidor com um chat"
Nas vendas corporativas russas, há uma frase que às vezes é pronunciada como um feitiço: "precisa estar em um circuito fechado".
Parte do mercado é cética em relação a isso: eles estão complicando tudo de novo, você não pode simplesmente pegar a nuvem de novo, os seguranças estão retardando o progresso de novo. Eu entendo essa irritação. Mas em circuitos grandes reais, um circuito fechado muitas vezes não é um capricho, mas um modelo normal de risco e ameaças.
Se você trabalha com materiais judiciais, documentos médicos, dados bancários, solicitações de cidadãos, compras, documentação técnica, regulamentos industriais ou segredos comerciais, a questão "posso enviar isso para um serviço externo?" deixa de ser filosófica.
Muitas vezes a resposta é: não.
Mas um circuito fechado não é "compramos um servidor com GPU e instalamos um chat".
São quatro camadas:
computação;
modelos;
camada operacional;
pessoas e processos.
Sem o primeiro, não há nada para calcular. Sem o segundo, não há nada para pensar. Sem o terceiro, não há ninguém para gerenciar. Sem o quarto, ninguém usará.
GPU sem filas, limites e proprietários não é infraestrutura, mas uma maneira muito cara de aquecer o ar.
Para grandes organizações, a questão não se resume a "nuvem ou on-prem". Precisamos de um modelo de implantação para a classe de dados: o que permanece dentro do perímetro, o que pode passar pelo gateway, quais modelos são permitidos, onde os embeddings são armazenados, quem gerencia as chaves, como os logs entram no circuito de segurança da informação e como o cenário é desativado em caso de incidente.
Em um circuito grande, a camada operacional de IA não pode viver separadamente da segurança da informação: identificação, funções, logs, segredos, integração com SIEM/SOC, segmentação de circuitos, controle de ações e um modelo de desativação devem ser projetados imediatamente, e não "após um piloto bem-sucedido".
A coisa mais difícil, aliás, quase sempre não é o hardware e nem o modelo. A coisa mais difícil são as pessoas. Não no sentido de "elas estão retardando". Mas no sentido de que um bom piloto de IA muda o comportamento da organização. As pessoas param de procurar manualmente. Param de copiar pedaços de documentos antigos. Param de lembrar de memória o que pode ser extraído com segurança do contexto. Param de tolerar a rotina, se viram uma vez que pode ser mais rápido.
O principal problema não é o lançamento, mas o escalonamento
O MVP hoje é montado rapidamente. Às vezes até rápido demais.
Um engenheiro forte e um cliente de negócios podem mostrar um cenário de trabalho em algumas semanas: pesquisa por regulamentos, rascunho de resposta, ata de reunião, verificação de documentos, análise de tickets, classificação de solicitações.
Na demonstração, tudo parece convincente.
Mas então começa a parte adulta:
os dados precisam ser atualizados regularmente;
os direitos de acesso precisam ser extraídos de sistemas corporativos reais;
a qualidade precisa ser medida não em três belos exemplos, mas em centenas de operações;
o resultado precisa ser incorporado ao local de trabalho do funcionário;
o departamento de segurança da informação deve entender o modelo de ameaças;
os negócios devem ver a economia;
o departamento de TI deve entender a operação;
o proprietário do processo deve estar pronto para alterar o regulamento.
É por isso que no CIPR-2026 já se falava abertamente: o problema dos negócios não é o lançamento de pilotos de IA, mas o escalonamento.
As estatísticas mundiais dizem o mesmo. No McKinsey State of AI 2025, quase nove em cada dez entrevistados dizem que suas organizações usam IA regularmente, mas a transição de pilotos para um impacto em larga escala nos negócios permanece incompleta para a maioria. O efeito é obtido não por aqueles que simplesmente conectaram o modelo, mas por aqueles que estão reconstruindo os processos, introduzindo regras, métricas, treinamento, verificação humana e incluindo a responsabilidade dos gerentes.
Para mim, o piloto termina não quando a demonstração agradou ao gerente, mas quando há um proprietário do processo, um conjunto de testes, métricas de qualidade, regras de acesso, um log de ações, a economia da operação e uma decisão: escalonamos, finalizamos ou fechamos.
A economia de um cenário de IA deve ser calculada não como "o custo da plataforma versus o salário do funcionário", mas o custo da operação antes/depois: tempo da pessoa, custo do modelo ou GPU, proporção de verificação manual, porcentagem de erros, custo do incidente e custo de suporte.
Um agente economiza horas. Cem agentes sem gerenciamento economizam seu sono. Mas o benefício da IA começa em escala. A escala sem uma camada operacional se transforma em caos.
O que é Unica AI tecnicamente
Se simplificarmos, Unica AI não é LLM e nem "chat com documentos". É uma camada de execução e gerenciamento de cenários de IA corporativos: entre pessoas, aplicativos de negócios, conhecimento, agentes, modelos e regras de segurança.
O primeiro circuito são as interfaces. Tem dois lados. O primeiro é uma interface para uma pessoa: um local de trabalho onde um funcionário se comunica com assistentes e agentes, faz perguntas, executa cenários, recebe respostas, rascunhos, protocolos, dados extraídos, tarefas e links para fontes. O segundo é uma interface para aplicativos de negócios: API, eventos, conectores, filas, webhooks, ferramentas MCP. Por meio dele, a camada de IA se conecta ao 1C, ECM, ERP, CRM, ITSM, Monq, BI, telefonia e portais internos. O objetivo não é incorporar IA separada em cada sistema, mas dar a todos os sistemas acesso a uma única camada de IA gerenciada.
O segundo circuito é o conhecimento. Aqui vivem o armazenamento markdown, o armazenamento de arquivos e o circuito RAG. O Markdown é conveniente para memória estruturada: instruções, regulamentos, prompts, cartões de cenário, notas de agentes. O armazenamento de arquivos é necessário para PDF, DOCX, XLSX, apresentações, digitalizações, áudio, anexos e artefatos de trabalho. E RAG já não é "uma pasta com arquivos", mas um pipeline: aceitar um documento, analisá-lo, dividi-lo em chunks, construir embeddings, vincular à fonte, atualizar, excluir, versionar e levar em conta os direitos de acesso. Simplificando: arquivos e markdown são memória e matéria-prima, RAG é uma maneira de extrair com segurança o contexto necessário dessa memória. Para os assistentes, o RAG é crítico, porque eles devem responder com fontes. Para os agentes, os arquivos de trabalho também são importantes como o estado da tarefa, resultados intermediários e memória gerenciada do cenário.
O terceiro circuito é o agente runtime: workflow, regras do agente executor básico, tools, skills, MCP, instruções do sistema, prompts, lógica de aprovação e ciclo de vida dos cenários. O assistente geralmente responde: encontrou, explicou, referiu-se à fonte. O agente faz: classifica a solicitação, verifica o conjunto de documentos, compara as versões do contrato, prepara um rascunho, cria uma tarefa, chama a ferramenta permitida, executa o workflow. E aqui o agente já não deve ser "um script com fantasia". Ele deve ter direitos, restrições, um proprietário, um log de ações, sandbox/dry-run, regras de parada e um ciclo de vida: draft → test → pilot → production → disabled → archived.
O quarto circuito são modelos e AI Gateway. Na IA corporativa, quase nunca haverá um modelo para tudo. Um LLM é mais adequado para respostas rápidas, outro para análise de documentos, um terceiro para código, OCR, ASR, TTS, embeddings, rerankers, modelos on-prem locais e, às vezes, APIs externas são necessários separadamente. O AI Gateway é necessário como um único ponto de gerenciamento: roteamento, prioridades, fallback, chaves, limites, tokens, faturamento, cotas por usuários e cenários, modelos permitidos para diferentes classes de dados. Esta é a camada que responde a perguntas desagradáveis, mas importantes: qual modelo foi chamado, por que ele, quanto custou, era possível enviar esses dados para lá e quem queimou o orçamento.
O quinto circuito é segurança e operação. Aqui vivem usuários, funções, direitos, espaços, políticas de acesso, auditoria, um log de solicitações e ações, monitoramento de segurança, monitoramento de desempenho, análise de uso, conjuntos de avaliação, controle de qualidade, alertas, análise de incidentes e "pulso de implementação": quem realmente usa o sistema, quais cenários decolaram, onde o custo está crescendo, onde a qualidade está caindo, quais assistentes precisam ser finalizados ou desativados. Sem isso, a IA corporativa permanece uma bela demonstração que todos elogiam, mas ninguém ousa colocar em operação industrial.
Importante: tudo isso pode ser montado em open source. Um bom exemplo é o artigo Sminex sobre uma plataforma LLM corporativa: Open WebUI como uma única janela para os funcionários, LiteLLM como AI Gateway, Langflow e MCP para cenários e ferramentas, vLLM/Ollama para inferência, RAGFlow e seus próprios RAG-pipeline para conhecimento, Prometheus/Grafana e Langfuse para observabilidade. Sua principal conclusão é próxima a mim: o open source acelera o início, mas a dor se manifesta nas junções - versões, compatibilidade, auth, atualizações, depuração, limites, observabilidade e operação.
Mas se você montar tudo isso sozinho, você está realmente começando a construir um produto de IA interno. Ele precisa ser projetado, atualizado, protegido, monitorado, documentado, treinar usuários e dar suporte nas junções. E nos circuitos empresariais russos, questões legais com licenças, responsabilidade pelo trabalho e suporte, riscos de sanções, repositórios fechados, requisitos de segurança da informação, 152-FZ, registro de software, independência de importação e muito mais são adicionados. Portanto, o open source é uma ótima maneira de provar a arquitetura. Mas um circuito industrial precisa de uma camada operacional montada, verificada e suportada, de preferência com um fornecedor do outro lado do fio que o ajudará a reduzir os riscos.
Esquematicamente, fica assim:
Neste esquema, o Monq não perde o papel. Pelo contrário, torna-se uma das fontes mais importantes de contexto operacional para o tratamento de incidentes e um meio de controle e observabilidade da plataforma de IA. Mas a IA permanece uma classe separada, porque gerencia não apenas incidentes, mas o trabalho digital da empresa.
O mesmo padrão surge em um banco, varejo ou setor público. Não basta o agente "responder com base no conhecimento". Ele precisa verificar os documentos, acessar vários sistemas, levar em conta a função do usuário, não mostrar o supérfluo, referir-se à fonte, solicitar confirmação antes da ação e deixar um log.
Isso já não é um chat. É um processo gerenciado.
Por que decidimos que o circuito básico deve ser aberto
O Monq tem uma versão gratuita. Ajudou o mercado a tocar o produto, mas a gratuidade em si não faz um padrão. Com o Unica AI, decidimos ir mais longe.
O circuito básico deve ser aberto, porque a camada que funciona com dados corporativos, modelos, agentes e auditoria não deve ser uma caixa preta. Qualquer coisa pode cair de tal caixa: um vazamento de chaves, uma chamada estranha para um modelo externo, um prompt inseguro ou uma dependência que ninguém verificou.
O problema de tal caixa preta é resolvido por um alto nível de
