Quando inteligência artificial encontra dados, produtividade e governança

A inteligência artificial deixou de ser apenas uma discussão sobre modelos de linguagem.

No ambiente corporativo, a questão mais complexa passou a ser outra:

Como utilizar IA sobre dados reais sem transformar produtividade em um novo vetor de risco?

Essa pergunta ganha ainda mais relevância no setor bancário.

Instituições financeiras trabalham com grandes volumes de informação, diferentes níveis de acesso, requisitos de segurança, processos regulados e sistemas que precisam operar com disponibilidade e controle.

Nesse cenário, ferramentas como o Microsoft 365 Copilot e o Microsoft Copilot Studio representam uma mudança interessante de perspectiva.

A IA deixa de ser apenas uma ferramenta para gerar texto.

Ela passa a interagir com informação corporativa, identidade, permissões, processos e agentes.

E é exatamente aí que começa a parte mais interessante para quem pensa como profissional de tecnologia.

1. Copilot não é simplesmente “um ChatGPT dentro do Office”

Uma das primeiras armadilhas conceituais é reduzir o Microsoft Copilot a um chatbot.

O Microsoft 365 Copilot está integrado ao ecossistema Microsoft 365 e utiliza o contexto disponível ao usuário para produzir respostas e auxiliar em tarefas.

A arquitetura considera identidade e permissões existentes. Segundo a documentação da Microsoft, o Copilot acessa apenas os dados aos quais o usuário já possui autorização. Também respeita controles existentes de acesso, rótulos de sensibilidade, políticas de retenção e mecanismos de auditoria.

Isso gera uma provocação importante:

Se a IA respeita as permissões existentes, a qualidade da segurança do Copilot depende também da qualidade das permissões existentes?

A resposta lógica é sim.

Se uma organização possui permissões excessivamente amplas ou dados compartilhados de maneira inadequada, introduzir uma camada de IA pode tornar informações existentes mais fáceis de localizar e sintetizar.

Portanto:

IA segura não começa necessariamente na IA.

Pode começar na governança dos dados.

2. O verdadeiro combustível do Copilot: contexto

Um modelo de linguagem pode gerar uma resposta.

Mas uma resposta corporativa útil precisa de contexto.

Imagine um profissional de tecnologia bancária trabalhando com:

• documentos;
• reuniões;
• e-mails;
• apresentações;
• planilhas;
• procedimentos;
• informações corporativas.

O valor de uma ferramenta de IA corporativa não está apenas na capacidade linguística do modelo.

Está também na capacidade de trabalhar dentro do contexto autorizado daquele usuário.

A documentação da Microsoft descreve justamente essa arquitetura: o Copilot utiliza o contexto da tarefa e os dados aos quais o usuário possui acesso para produzir uma resposta relevante.

Então surge uma pergunta que parece simples, mas é arquiteturalmente profunda:

Quanto mais contexto entregamos à IA, maior é a utilidade — mas também precisamos aumentar proporcionalmente a governança?

Essa é uma das tensões centrais da IA corporativa.

3. No banco, “mais informação” não significa necessariamente “melhor informação”

Imagine dois usuários.

O primeiro trabalha com informações operacionais.

O segundo possui acesso a documentos estratégicos e informações restritas.

Se ambos utilizarem uma solução de IA corporativa, a experiência não deveria ser necessariamente igual.

A autorização precisa continuar sendo determinante.

A Microsoft documenta que o Microsoft 365 Copilot utiliza os controles de identidade e acesso existentes e não deve acessar dados para os quais o usuário não possui permissão.

Isso nos leva a uma questão crítica:

O problema está na IA ou está no modelo de autorização que já existia antes dela?

Essa pergunta é especialmente relevante em ambientes bancários.

A IA pode revelar uma fragilidade que já estava presente.

4. Copilot e o princípio do menor privilégio

Em segurança da informação, o princípio do menor privilégio busca limitar o acesso de uma identidade ao mínimo necessário para executar sua função.

Quando introduzimos IA em processos corporativos, esse conceito ganha uma nova dimensão.

Antes:

Usuário → Sistema → Informação

Agora podemos ter:

Usuário → Copilot → Contexto → Dados → Modelo → Resposta

Em cenários mais avançados:

Usuário → Agente → Ferramentas → APIs → Sistemas corporativos

Cada nova conexão cria uma superfície adicional que precisa ser governada.

A própria documentação de segurança do Copilot Studio recomenda controles de acesso baseados em função, Microsoft Entra ID e aplicação do princípio do privilégio mínimo.

A provocação é direta:

Se um agente pode executar uma ação que antes exigia vários passos humanos, como devemos controlar essa nova capacidade?

Essa pergunta já ultrapassa produtividade.

Entramos em arquitetura de segurança.

5. Microsoft Copilot Studio: quando o Copilot começa a agir

Existe uma diferença importante entre utilizar IA para auxiliar uma tarefa e construir agentes capazes de executar fluxos.

O Microsoft Copilot Studio permite criar agentes que podem utilizar fontes de conhecimento, conectores, ações e integrações.

A Microsoft documenta mecanismos de governança para controlar essas capacidades, incluindo políticas de dados, autenticação, fontes de conhecimento, conectores, ações, solicitações HTTP, publicação e gatilhos.

Isso cria uma mudança de paradigma:

Copilot como assistente

Perguntar → receber resposta

Agente

Receber contexto → raciocinar → utilizar ferramentas → executar ações

Quanto mais próximo estamos do segundo modelo, maior precisa ser a preocupação com controles.

Porque uma resposta incorreta pode exigir apenas uma correção humana.

Uma ação incorreta pode produzir uma consequência operacional.

6. O problema não é apenas a alucinação

Quando falamos de IA generativa, frequentemente surge a preocupação com hallucinations, ou seja, respostas que apresentam informações incorretas ou não sustentadas pelas fontes disponíveis.

É um risco importante.

Mas, em um ambiente corporativo, existe uma pergunta ainda mais interessante:

E se a resposta estiver correta, mas o usuário não deveria ter acesso à informação utilizada para produzi-la?

Nesse cenário, o problema não é exatamente a capacidade do modelo de gerar texto.

É controle de acesso e governança de dados.

Essa distinção é fundamental.

Podemos ter:

Resposta incorreta → problema de confiabilidade

Resposta correta para usuário não autorizado → problema de segurança

Ação correta executada no contexto errado → problema operacional

A IA corporativa precisa lidar com os três.

7. Segurança não termina no modelo

Uma arquitetura de IA empresarial não pode ser analisada apenas olhando para o LLM.

Precisamos observar o ecossistema.

Uma visão simplificada poderia ser:

Identidade

↓

Permissões

↓

Dados

↓

Copilot / Agente

↓

Modelo de IA

↓

Ferramentas / Conectores

↓

Ação ou resposta

↓

Auditoria

Cada camada possui perguntas diferentes.

Identidade

Quem está fazendo a solicitação?

Permissões

O usuário pode acessar aquela informação?

Dados

A informação utilizada é apropriada para aquela finalidade?

Modelo

A resposta é confiável?

Conectores

Quais sistemas podem ser acessados?

Ação

O agente pode alterar alguma coisa?

Auditoria

Conseguimos reconstruir o que aconteceu?

Essa visão sistêmica é muito mais importante do que simplesmente perguntar:

“Qual modelo o Copilot usa?”

8. Governança: o lado menos glamouroso da IA

A palavra “IA” costuma despertar interesse.

A palavra “governança” talvez não.

Mas, em ambientes corporativos, as duas precisam andar juntas.

A Microsoft documenta mecanismos de governança para Copilot Studio que incluem políticas de dados, DLP, controle de conectores, auditoria e gerenciamento de ambientes.

Também existem estratégias para separar ambientes de desenvolvimento, teste e produção, com diferentes níveis de governança conforme o risco e a finalidade do agente.

Isso aproxima a construção de agentes de conceitos já conhecidos na engenharia de software:

Desenvolvimento → Teste → Produção

E adiciona uma nova dimensão:

Governança de IA

9. O agente precisa ter “permissão para pensar” ou “permissão para agir”?

Aqui está uma provocação que considero particularmente interessante.

Imagine um agente conectado a sistemas corporativos.

Ele consegue consultar informações.

Isso já exige controle.

Agora imagine que ele também possa executar uma ação.

A arquitetura mudou.

Podemos representar:

Read

↓

Consultar informação.

ou

Write

↓

Modificar informação.

A segunda situação exige uma análise muito mais rigorosa.

Em um ambiente bancário, a pergunta poderia ser:

Quais ações um agente deveria poder executar autonomamente e quais deveriam obrigatoriamente exigir aprovação humana?

Essa discussão conecta IA a conceitos conhecidos de controle interno, segregação de funções e gestão de riscos.

10. O problema do “Shadow AI”

Existe outro fenômeno importante.

Uma organização pode estabelecer uma estratégia oficial de IA enquanto colaboradores utilizam ferramentas externas por conta própria.

Surge então o chamado Shadow AI.

O problema não é simplesmente “usar IA”.

A questão é:

Quais dados estão sendo enviados para quais ferramentas, sob quais políticas e com qual nível de controle?

Uma solução corporativa como Microsoft 365 Copilot procura trabalhar dentro de mecanismos empresariais de identidade, segurança e governança. A Microsoft também apresenta controles específicos para governar Copilot e agentes dentro do ambiente organizacional.

Isso não elimina a necessidade de governança.

Pelo contrário.

Mostra que adoção de IA precisa ser tratada como decisão de arquitetura e gestão de risco, não apenas como aquisição de uma ferramenta.

11. Copilot + dados: a pergunta que um Tech Leader deveria fazer

Imagine que uma área queira implantar um agente para consultar documentos internos.

A pergunta inicial poderia ser:

“Qual será o ganho de produtividade?”

É uma pergunta válida.

Mas um Tech Leader deveria ampliar o raciocínio:

• Quais fontes serão utilizadas?
• Quem possui acesso a essas fontes?
• Como os acessos serão herdados?
• Quais conectores estarão disponíveis?
• O agente poderá executar ações?
• Como serão tratados dados sensíveis?
• Quais logs serão mantidos?
• Como será feita a auditoria?
• Como o agente será promovido entre ambientes?
• Como será revogado o acesso?
• O que acontece quando uma fonte de conhecimento muda?

Perceba a mudança.

A conversa deixa de ser:

“Vamos colocar IA aqui.”

E passa a ser:

“Vamos desenhar uma capacidade de IA governável.”

12. Uma arquitetura mental para o ambiente bancário

Podemos pensar em uma arquitetura conceitual:

               USUÁRIO
                  │
                  ▼
            IDENTIDADE
                  │
                  ▼
           AUTORIZAÇÃO
                  │
                  ▼
        ┌─────────────────┐
        │     COPILOT     │
        │    / AGENTE     │
        └─────────────────┘
           │           │
           ▼           ▼
        DADOS       FERRAMENTAS
           │           │
           ▼           ▼
     CONHECIMENTO     APIs
           │           │
           └─────┬─────┘
                 ▼
           MODELO DE IA
                 │
                 ▼
           RESPOSTA/AÇÃO
                 │
                 ▼
        MONITORAMENTO
        E AUDITORIA

Isso não representa uma arquitetura proprietária de um banco específico.

É apenas um modelo conceitual para raciocinar sobre as principais camadas envolvidas.

E é justamente esse tipo de raciocínio que permite avaliar uma tecnologia sem depender de marketing.

13. A pergunta que pode separar usuário de tecnologia de profissional de tecnologia

É relativamente fácil aprender:

“Como utilizar o Copilot?”

Uma pergunta mais madura seria:

“Como permitir que o Copilot seja útil sem ampliar indevidamente a superfície de acesso aos dados?”

E uma pergunta ainda mais avançada:

“Como medir se o ganho de produtividade justifica o risco adicional introduzido pela automação?”

Agora estamos falando de arquitetura.

Estamos falando de segurança.

Estamos falando de governança.

E estamos falando de tecnologia aplicada ao negócio.

14. Um exercício de raciocínio

Imagine um banco criando um agente interno para auxiliar equipes de tecnologia.

O agente pode:

• consultar documentação;
• localizar procedimentos;
• resumir informações;
• orientar troubleshooting;
• consultar determinadas fontes corporativas.

Até aqui, parece relativamente controlado.

Agora adicione uma capacidade:

“Executar uma ação em um sistema corporativo.”

A pergunta imediatamente muda:

Quem autorizou essa ação?

Depois:

O agente está utilizando a identidade do usuário ou uma identidade própria?

Depois:

Existe segregação entre consulta e execução?

Depois:

Existe aprovação humana?

Depois:

Existe log?

Depois:

É possível reconstruir o motivo da ação?

Essa sequência de perguntas demonstra algo importante:

a maturidade de uma solução de IA não é determinada apenas pela inteligência do modelo.

Ela também é determinada pela qualidade da arquitetura ao redor dele.

15. O futuro não é apenas “IA que responde”

A evolução mais interessante não está necessariamente em respostas cada vez mais sofisticadas.

Está na combinação entre:

IA + dados + identidade + APIs + automação + governança

Quando esses componentes são integrados, o sistema deixa de ser apenas conversacional.

Ele passa a participar de processos.

É nesse ponto que conceitos tradicionais de tecnologia continuam extremamente importantes:

• arquitetura;
• segurança;
• APIs;
• bancos de dados;
• controle de acesso;
• observabilidade;
• DevOps;
• ALM;
• governança;
• gestão de riscos.

A IA não elimina esses conceitos.

Ela aumenta a importância deles.

16. A provocação final

Talvez a pergunta mais importante sobre Microsoft Copilot em um ambiente bancário não seja:

“O que o Copilot consegue fazer?”

Mas:

“O que deveríamos permitir que ele faça?”

Existe uma diferença enorme entre capacidade técnica e capacidade autorizada.

Uma tecnologia pode ser capaz de:

consultar → resumir → recomendar → decidir → executar

Mas uma arquitetura corporativa madura precisa determinar:

o que pode ser feito, por quem, em quais dados, em qual ambiente, sob quais políticas e com qual nível de supervisão.

Essa é a fronteira entre experimentar IA e engenheirar IA.

Conclusão

O Microsoft Copilot representa uma evolução importante na forma como profissionais interagem com informações e ferramentas corporativas.

Mas, no ambiente bancário, produtividade não pode ser analisada isoladamente.

O verdadeiro desafio está em equilibrar:

Produtividade + Dados + Segurança + Identidade + Governança + Risco

A documentação atual da Microsoft mostra que esse ecossistema já incorpora mecanismos de segurança, políticas de dados, controle de conectores, auditoria, gestão de ambientes e proteção de dados corporativos.

Isso não significa que a ferramenta resolva automaticamente todos os desafios de uma instituição financeira.

Significa que existe uma arquitetura de controles que precisa ser compreendida, configurada e governada.

E talvez essa seja a principal provocação para quem deseja trabalhar com tecnologia bancária:

A pergunta não é se a IA consegue acessar o dado.

A pergunta profissional é: ela deveria conseguir?

E se deveria, como provar que esse acesso foi seguro, necessário, autorizado e auditável?

Quando começamos a fazer essas perguntas, deixamos de olhar para o Copilot apenas como uma ferramenta de produtividade.

Passamos a enxergá-lo como aquilo que ele pode se tornar dentro de uma arquitetura corporativa:

uma nova camada de interação entre pessoas, dados, sistemas e inteligência artificial.

E é exatamente nessa camada que tecnologia, segurança e negócio começam a conversar.

Referências técnicas

• Microsoft Learn — Microsoft 365 Copilot: arquitetura, acesso e privacidade.
• Microsoft Learn — Enterprise Data Protection no Microsoft 365 Copilot.
• Microsoft Learn — Segurança do Microsoft 365 Copilot.
• Microsoft Learn — Segurança e governança do Microsoft Copilot Studio.
• Microsoft Learn — Políticas de dados para agentes do Copilot Studio.
• Microsoft Learn — Estratégia de governança por zonas para agentes.

Nota de rigor: os cenários apresentados neste artigo são exercícios conceituais de arquitetura e raciocínio técnico. Não representam arquiteturas internas, métricas, incidentes ou casos operacionais de bancos específicos.