Esta seção documenta as restrições técnicas e organizacionais que delimitam o escopo da solução CRP.AI. Estas são condições que a arquitetura deve respeitar.
2.1 Infraestrutura On-Premises
O módulo CRP.AI no Olimpo e o AI Gateway operam em ambiente próprio da CRP Tecnologia. Provedores de modelo ou integrações equivalentes permanecem dependências do gateway.
| Item | Restrição |
|---|---|
| Orquestração | OpenShift (Kubernetes) em cluster próprio, registrado sob domínio corporativo da CRP Tecnologia |
| Registry de imagens | registry.fabricacrp.com.br — todas as imagens de container (Olimpo API, LiteLLM customizado) residem internamente |
| Deploy | ArgoCD com sincronização automatizada. |
| Roteamento | OpenShift Routes (route.openshift.io/v1) para exposição HTTP/HTTPS dos serviços |
| Monitoramento | Prometheus self-hosted, conectado aos sistemas que compõem a solução CRP.AI |
Impacto: o gateway, a gestão de chaves e o registro de uso permanecem sob gestão da CRP. O fluxo e a retenção de dados por integrações de observabilidade dependem da topologia adotada e devem ser documentados antes da ativação.
LangFuse deve ser tratado como integração de observabilidade. A topologia de implantação, seja interna ou externa, precisa ser confirmada antes de classificá-lo como dependência on-premises.
2.2 Keycloak como SSO Corporativo
A autenticação de usuários no Olimpo é delegada ao Keycloak corporativo, já estabelecido nos ambientes da CRP Tecnologia. O consumo de modelos pelas ferramentas dos colaboradores é autenticado no AI Gateway por virtual key.
| Item | Restrição |
|---|---|
| Realm | CRPTecnologia |
| Endpoint | https://sso.crptecnologia.com.br/realms/CRPTecnologia |
| Federação de identidade | Usuários autenticados via AD corporativo |
| Mecanismo de autenticação | JWT (JSON Web Token) emitido pelo Keycloak, validado pelo Olimpo API via Spring Security OAuth2 Resource Server |
| Client credentials | Suporte a OAuth2 Client Credentials Grant para comunicação serviço-a-serviço. |
Impacto: a identidade do colaborador no CRP.AI é a mesma do Azure DevOps. O identificador do usuário (username) corresponde ao handle do Azure DevOps. Não há criação de credenciais separadas — a federação mantém a experiência de single sign-on.
2.3 Azure DevOps
O Azure DevOps Server on-premises é o ecossistema de desenvolvimento da organização. No contexto do CRP.AI, seu papel é limitado à configuração do MCP (Model Context Protocol) para o OpenCode, permitindo que assistentes de IA interajam com repositórios e work items.
| Item | Restrição |
|---|---|
| MCP | Configuração do servidor MCP Azure DevOps integrada ao fluxo do CRP.AI Installer |
2.4 Segurança de Rede
O CRP.AI impõe isolamento de rede como princípio fundamental de segurança:
| Item | Restrição |
|---|---|
| AI Gateway não exposto externamente | No fluxo suportado, o gateway não possui rota pública e clientes externos à rede interna da CRP não o acessam diretamente. Na implantação atual, esse papel é exercido pelo LiteLLM Proxy. |
| Comunicação com AI Gateway | Olimpo API usa a API administrativa do gateway para governança. Colaboradores comunicam-se diretamente com o gateway para consumo de IA. |
| Rede interna isolada | O LiteLLM Proxy e seu banco de dados PostgreSQL residem em rede interna. |
| Comunicação com provedores | O AI Gateway inicia conexões de saída para os provedores configurados, usando as credenciais mantidas pelo gateway. Na implantação atual, essa operação é executada pelo LiteLLM Proxy. |
2.5 Bancos de Dados
O CRP.AI utiliza dois bancos de dados distintos, cada um com finalidade específica:
| Banco | SGBD | Finalidade | Esquema |
|---|---|---|---|
| Olimpo | PostgreSQL | Dados de aplicação do Olimpo: times, chaves (metadados), permissões, budgets, notificações e auditoria. Gerido via Liquibase (db.changelog-master.xml). |
public (padrão) |
| LiteLLM | PostgreSQL | Dados operacionais do gateway: virtual keys, teams, budgets, modelos configurados, logs de requisições (spend logs). Gerido pelo próprio LiteLLM (STORE_MODEL_IN_DB: True). |
Gerenciado pelo LiteLLM |
Impacto: a separação de bancos garante que o ciclo de vida do LiteLLM (upgrades, migrações de schema) não afete os dados de aplicação do Olimpo e vice-versa.
2.6 Provedores de Modelo
A seleção e configuração de provedores de IA seguem restrições específicas:
| Item | Restrição |
|---|---|
| Interface de consumo | O AI Gateway expõe a interface adotada pelo CRP.AI, compatível com o padrão OpenAI API. Na implantação atual, o LiteLLM Proxy traduz requisições quando o adaptador necessário está disponível. |
| Credenciais | Chaves de API dos provedores são mantidas no AI Gateway; o módulo CRP.AI no Olimpo não as administra. |
| Provedores suportados | OpenAI, Azure OpenAI, Anthropic, AWS Bedrock, Google Gemini e Ollama. Ollama é uma integração que pode ser implantada localmente. A inclusão técnica de provedores é responsabilidade do operador do gateway. |
| Seleção de modelo | O colaborador usa um identificador de modelo aceito pelo AI Gateway; o gateway o interpreta conforme sua configuração técnica. |
| Rate limiting | O AI Gateway aplica limites por virtual key. O módulo CRP.AI define parâmetros corporativos por sua API administrativa. |
Impacto: a restrição de compatibilidade com OpenAI API permite usar ferramentas do ecossistema, como OpenCode, Continue, Cursor e CLIs, com menor necessidade de adaptação. A centralização de credenciais no LiteLLM reduz o risco de chaves de provedor expostas em máquinas de colaboradores.
Uma alteração administrativa pode ser registrada no Olimpo antes de a operação correspondente ser concluída no AI Gateway. Falhas de integração exigem nova tentativa ou reconciliação; elas não deslocam o fluxo de inferência para o Olimpo.
2.7 Resumo das Restrições
| # | Categoria | Restrição Principal |
|---|---|---|
| 1 | Infraestrutura | Gateway e componentes de gestão em ambiente próprio; provedores de modelo são dependências externas. |
| 2 | Identidade | Keycloak realm CRPTecnologia para autenticação no Olimpo; virtual keys para consumo de modelos pelo gateway. |
| 3 | Repositório | Azure DevOps Server (código-fonte) |
| 4 | Rede | AI Gateway isolado da rede externa. Colaboradores acessam o gateway diretamente; Olimpo API usa sua API administrativa para gestão. |
| 5 | Dados | PostgreSQL para Olimpo e LiteLLM (instâncias separadas). SQL Server read-only para Azure DevOps. |
| 6 | Modelos | Interface de consumo compatível com OpenAI API. Credenciais de provedores centralizadas no LiteLLM. |