Por que falar de IA como capacidade (e não como “feature”)
Em sistemas corporativos, IA só é útil quando cabe no mundo real: dados sensíveis, permissões, auditoria, integrações e risco operacional. Por isso, faz mais sentido enxergá-la como uma capacidade que atravessa o ciclo inteiro do software — com pontos de encaixe diferentes e com controles diferentes — do que como uma promessa única de “automação”.
Na Thinkwise, esse encaixe costuma ser entendido em três perspectivas: criar o software, colocar em produção e operar, e usar o software no dia a dia.
Criar o software (Software Factory e Upcycler)
No desenvolvimento, IA pode apoiar atividades repetitivas e textuais. Por exemplo: enriquecer descrições, ajudar na organização de conhecimento do domínio e acelerar tarefas de análise e refinamento. Como a plataforma é orientada a modelos, esse tipo de apoio tende a ser mais útil quando mantém rastreabilidade e revisão humana: a IA sugere, o time valida e publica.
No Upcycler, a mesma lógica se aplica ao ponto de partida: o objetivo não é “traduzir o legado automaticamente”, e sim acelerar a criação de uma base inicial que o time consegue revisar e governar dentro do modelo.
Colocar em produção e operar (Indicium e IAM)
Do lado de operação, IA só faz sentido quando o desenho mantém controle de acesso e trilha de execução. É aqui que entram camadas como Indicium e IAM. Elas são o caminho natural para autenticação, autorização e auditoria, e por isso são relevantes quando você quer habilitar integrações que “tocam” dados e processos do sistema de forma segura.
Isso não elimina decisões suas. Contratos de integração, limites de ação, telemetria e tratamento de falhas continuam sendo parte do trabalho de arquitetura, principalmente quando a integração envolve agentes que podem executar ações.
Usar o software (Universal GUI ou UIs próprias via API)
No uso do software, IA costuma aparecer como parte da experiência: enriquecer textos, estruturar informações, apoiar decisões e reduzir trabalho manual em atividades de comunicação e classificação. Em alguns cenários, isso acontece por meio da própria Universal GUI. Em outros, por UIs específicas construídas pelo cliente, consumindo APIs e integrando provedores de IA (por exemplo, modelos de linguagem), conforme as políticas da organização.
MCP como direção possível: por que isso é relevante para uma plataforma orientada a modelos
O Model Context Protocol (MCP) é um padrão para conectar assistentes e agentes a fontes e ferramentas. Em uma plataforma orientada a modelos, ele é especialmente interessante porque modelos são, por natureza, estruturados e interpretáveis. Isso tende a reduzir esforço para transformar “conhecimento do sistema” em contexto útil, com menos dependência de extrações caso a caso.
Na prática, agentes trabalham melhor quando recebem contexto estruturado sobre dados e processos — mas isso não equivale a “entendimento” automático. Para ser útil e seguro, o agente precisa operar sob limites explícitos sobre o que pode ver e fazer. Também precisa de validação, auditoria e observabilidade das ações.
O MCP não substitui desenho de domínio nem resolve integração automaticamente. Ele padroniza o caminho de conexão entre agentes e sistemas governados.
Dependências e limites (o que decide risco)
Antes de discutir “IA no core”, vale alinhar quatro pontos que determinam viabilidade:
- Casos de uso e limites de ação: o que é sugestão e o que é execução.
- Dados e permissões: quem pode ver o quê, em quais contextos.
- Auditoria e rastreabilidade: que trilha precisa existir para compliance e suporte.
- Integração e observabilidade: contratos, telemetria e tratamento de falhas.
Para acompanhar atualizações públicas sobre direção e roadmap da plataforma (incluindo MCP), a Comunidade Thinkwise reúne posts e discussões (cadastro).