Entre em qualquer empresa no último ano e a história da IA costuma começar antes da estratégia. Alguém resumiu uma chamada com um cliente no ChatGPT. Um gestor de produto colou um backlog no Claude. Um analista pediu ao Copilot para explicar uma folha de cálculo que provavelmente não devia ter carregado para lado nenhum.
Nada disto é malicioso. As pessoas encontraram ferramentas que tornam trabalho difícil mais fácil, e usam-nas porque a empresa não lhes deu uma alternativa aprovada igualmente útil.
A resposta habitual é uma política que diz não. Bloquear os sites públicos, enviar um lembrete sobre informação confidencial e esperar que o problema tenha desaparecido.
Não desapareceu. Foi apenas para um sítio mais difícil de ver.
O problema da IA é um problema de controlo
As ferramentas públicas de IA são excelentes a pôr um primeiro rascunho na página. Também estão fora dos controlos que a maioria das organizações já usa para proteger os seus dados. A equipa de segurança não consegue ver de forma consistente o que está a ser submetido. O jurídico não consegue dar uma resposta clara sobre onde é processado. Um product owner não consegue restringir um assistente aos documentos de que realmente precisa. E quando um regulador, um cliente ou um membro do conselho pergunta quem teve acesso a quê, a resposta é muitas vezes um documento de política.
O risco não é que o ChatGPT, o Claude ou o Copilot sejam automaticamente inseguros. O risco é que uma conta de consumidor, um login pessoal ou um separador do browser não aprovado não são um modelo operacional empresarial. Não lhe dão a sua própria fronteira de identidade, a sua própria fronteira de rede, o seu próprio rasto de auditoria nem uma escolha de deployment que a sua equipa de proteção de dados possa rever.
Isso pesa mais na Europa. A residência de dados é agora uma pergunta de compras. O DORA, a NIS2, a regulação setorial e os contratos com clientes fizeram dela uma. Uma política de IA útil tem de responder a mais do que se as pessoas podem usar uma ferramenta. Tem de responder a que dados podem chegar até ela, quem pode perguntar, onde o pedido é processado e como o resultado é verificado antes de afetar um cliente ou uma decisão.
Proibir não é uma estratégia de IA
Pode proibir todos os assistentes públicos na empresa. As suas pessoas vão continuar a ver IA nas ferramentas que compram, nos fornecedores com quem trabalham e nos concorrentes que encontram. A pressão não desaparece porque a política diz não. Transforma-se em shadow IT, e a shadow IT é a forma menos governável de inovação que existe.
A melhor pergunta é: o que tornaria a coisa útil na coisa segura?
Para organizações que já correm no Azure, o Azure AI Foundry é a resposta. Dá ao negócio a capacidade que as pessoas procuram, ao mesmo tempo que coloca o modelo, a ligação aos dados e os controlos operacionais de volta dentro do ambiente Azure que a empresa já governa.
O que o Azure AI Foundry muda
O Foundry não é um chatbot. É a plataforma para construir e operar aplicações, assistentes e agentes de IA. As suas equipas podem escolher um modelo adequado, ligá-lo a dados de negócio aprovados, testar a qualidade das respostas e colocá-lo por trás de uma aplicação que usa o seu próprio modelo de identidade e acessos.
É essa a diferença entre pessoas a copiar informação sensível para uma caixa de prompt genérica e dar-lhes um assistente feito à medida que só conhece a documentação, os dados de produto ou o processo que precisa de conhecer.
Esse modelo operacional é a segunda metade que faltava em Agentes de IA feitos como deve ser: da experiência à plataforma empresarial, onde escrevemos sobre tratar os agentes de IA como infraestrutura desde o primeiro dia.
As capacidades importantes são simples.
Escolha sem mais uma plataforma. O catálogo de modelos permite às equipas escolher entre modelos apoiados pela Microsoft e outros modelos adequados para tarefas diferentes: resumir documentos, responder a perguntas sobre uma base de conhecimento aprovada, classificar um pedido ou ajudar um service desk. O modelo passa a ser uma escolha técnica e comercial deliberada, e não a ferramenta pública que alguém abriu primeiro.
Os dados continuam a fazer parte do seu ambiente. Para os modelos vendidos pelo Azure, a Microsoft afirma que prompts, respostas, embeddings e dados de treino não ficam disponíveis para outros clientes nem para fornecedores de modelos, e não são usados para treinar modelos fundacionais de IA generativa sem a sua autorização ou instrução. É um contrato materialmente diferente de assumir que uma ferramenta pública se comporta como um serviço empresarial privado. O compromisso exato continua a depender do modelo e do caminho de deployment, por isso confirme-o antes de aprovar um caso de uso, em vez de tratar um catálogo de modelos como uma garantia geral.
A identidade e as permissões continuam suas. Microsoft Entra ID, controlo de acessos baseado em funções e identidades geridas significam que uma pessoa ou um agente recebe apenas as permissões de que precisa. Um assistente de RH não herda acesso ao financeiro. Um assistente de produto não precisa da biblioteca de documentos inteira. Parece óbvio, mas é exatamente o controlo que falta quando prompts sensíveis saem por uma conta não gerida.
A rede não fica para depois. Private endpoints, integração com redes virtuais e Azure Policy podem manter a carga de trabalho dentro das mesmas fronteiras das aplicações e dos dados que serve. As chaves ficam no Key Vault. O acesso é registado. As políticas podem impedir que uma configuração conveniente mas não conforme chegue discretamente à produção.
Qualidade e segurança são operadas, não presumidas. O Foundry dá às equipas capacidades de avaliação, rastreio e monitorização para testarem se um assistente é preciso, se está ancorado nas fontes certas e se se comporta como pretendido. O Content Safety e os Prompt Shields acrescentam mais uma camada onde um assistente lida com input externo. Um modelo deve ser útil antes de ser lançado, observável depois de lançado e parado quando cruza uma fronteira. É assim que se opera software. A IA não devia ter uma isenção especial.
A localização dos dados é uma escolha de desenho, não um logótipo
Esta é a parte a levar a sério. Correr no Azure não significa automaticamente que cada pedido fica num país específico, ou sequer na UE. O tipo de deployment importa.
Um deployment Global pode processar prompts e respostas em localizações Azure de todo o mundo, embora os dados armazenados em repouso fiquem na geografia Azure que escolheu. Pode ser a escolha certa para uma carga de trabalho de baixo risco e grande escala. Não é a escolha a fazer por acidente para registos de clientes, dados regulados ou propriedade intelectual.
Para cargas de trabalho que exigem processamento na UE, escolha o modelo e o caminho de deployment em conformidade. Com um deployment DataZone criado num Estado-Membro da UE, os prompts e as respostas podem ser processados nesse país ou noutro Estado-Membro da UE. Onde o requisito é uma região Azure específica, use um deployment regional e confirme a disponibilidade do modelo nessa região. A diferença pertence ao registo de desenho e à avaliação de risco, não enterrada nas notas de configuração de uma equipa de plataforma.
Os dados armazenados precisam da mesma atenção. Histórico de conversas, ficheiros carregados, índices vetoriais e logs de aplicação podem ter, cada um, as suas próprias características de retenção e localização. O Foundry dá-lhe os controlos para desenhar isto como deve ser; não elimina a necessidade de classificar dados, definir regras de retenção e decidir o que nunca deve ser enviado a um modelo.
Por outras palavras: a localização dos dados não é uma afirmação de marketing. É uma decisão de arquitetura que as suas equipas de segurança, jurídico e produto podem inspecionar.
Dê às pessoas uma forma aprovada de usar IA
O primeiro caso de uso não precisa de ser um grande programa de transformação. Escolha uma tarefa que as pessoas já fazem em ferramentas públicas: encontrar uma resposta na documentação interna, redigir uma resposta a partir de modelos aprovados, resumir um processo ou classificar um pedido recebido.
Construa um assistente à volta de um conjunto de dados pequeno e aprovado. Dê-lhe uma identidade gerida com acesso de privilégio mínimo. Mantenha o endpoint privado onde a carga de trabalho o exigir. Escolha o deployment regional ou DataZone na UE correto. Teste-o com exemplos reais mas controlados. Registe os resultados. Ponha uma pessoa no ponto em que o resultado se torna uma comunicação a um cliente, uma decisão financeira ou uma alteração a um sistema.
A partir daí, a política torna-se mais fácil de aplicar, porque já não pede às pessoas que abdiquem de uma capacidade útil. Dá-lhes o sítio aprovado para a usar.
É esse o verdadeiro valor do Azure AI Foundry. Não é uma caixa de prompt mais bonita. É a plataforma de IA empresarial para empresas que querem a velocidade que as suas pessoas já conseguem ver, sem abdicar do controlo sobre os dados, a identidade e a localização que fazem do negócio o seu negócio.
Não há uma abordagem única para a cloud. É por isso que partimos da realidade da sua organização.
A IA já está na sua organização. Decidir onde corre, com que identidade e sob que controlos continua a ser uma decisão sua, e é mais fácil tomá-la agora do que sob o prazo de uma auditoria. Marque uma conversa direta com o CTO da DevOps Masterminds, Rinie Huijgen.
