Um código para o modelo não é uma política pronta para a empresa
Em 14 de setembro de 2026, a Microsoft AI publicou para consulta pública um Código de Conduta de IA Humanista. O documento descreve comportamentos, valores e limites pretendidos para os modelos MAI e apresenta uma hierarquia entre o código do desenvolvedor, as políticas dos operadores e as preferências dos usuários.
A iniciativa é relevante porque torna explícita uma ideia que costuma permanecer escondida na tecnologia. Um modelo não chega à organização como capacidade neutra. Ele traz decisões sobre o que deve recusar, como deve agir diante de incerteza, a quem deve obedecer e que objetivos devem prevalecer quando há conflito.
Para a liderança empresarial, no entanto, o documento não resolve a governança local. A própria Microsoft afirma que o texto ainda está em desenvolvimento, não é usado hoje para treinar seus modelos e não garante o comportamento atual. A constituição do fornecedor pode formar a primeira camada de controle. A empresa ainda precisa escrever as regras que ligam o modelo ao seu negócio.
A cadeia de comando revela três responsabilidades diferentes
O código propõe uma cadeia de comando. As restrições absolutas e os requisitos de controle humano ocupam o nível superior. Em seguida aparecem as políticas dos operadores, definidos como desenvolvedores, construtores e parceiros empresariais que configuram os modelos para contextos específicos. Depois vêm as preferências dos usuários.
Essa ordem evita que uma preferência individual anule uma proteção fundamental. Ao mesmo tempo, deixa claro que existe um espaço amplo de decisão entre a regra geral do modelo e a solicitação da pessoa. É nesse espaço que a organização determina finalidade, público, dados disponíveis, ações permitidas, forma de revisão e critérios de escalonamento.
A empresa não deve confundir essas camadas. O fornecedor responde pelos limites e comportamentos que declara para o modelo. O operador responde pela configuração e pelo uso institucional. O usuário responde pelo pedido dentro das permissões recebidas. Quando tudo é tratado como uma única responsabilidade da tecnologia, os vazios entre as camadas se tornam invisíveis.
Princípio geral precisa encontrar consequência concreta
Uma afirmação como manter pessoas no controle oferece direção, mas não define sozinha o que fazer em um processo de crédito, atendimento, contratação, marketing ou manutenção. Controle pode significar revisão antes de uma ação, possibilidade de interrupção, limite de valor, separação de funções ou direito de contestação. A escolha depende da consequência.
A regra empresarial começa com verbos observáveis. O agente pode consultar, comparar, recomendar, redigir, enviar, alterar, aprovar ou executar? Cada verbo muda o risco. Também precisa indicar sobre quais dados, para qual público, em que ambiente e com qual possibilidade de reversão a ação é aceita.
Sem essa tradução, um princípio pode ser repetido em apresentações enquanto o sistema opera por decisões implícitas. A política fica abstrata e a configuração técnica se torna a regra real. Escrever a regra local é trazer a decisão de volta para quem compreende o processo e responderá por seus efeitos.
O contexto do operador não pode caber apenas em um prompt
É comum inserir instruções do negócio no começo de uma conversa ou em uma mensagem de sistema. Esse recurso ajuda a orientar linguagem e comportamento, mas não deve carregar sozinho toda a governança. Prompts podem ficar desatualizados, ser interpretados de forma inesperada ou perder força diante de contextos longos e integrações complexas.
Regras críticas precisam aparecer também fora do texto enviado ao modelo. Permissões devem limitar ferramentas e dados. Validações determinísticas devem impedir formatos ou ações proibidas. Aprovações devem ocorrer antes de consequências sensíveis. Registros precisam conservar quem pediu, que versão atuou, quais fontes foram usadas e o que o sistema fez.
A política empresarial, portanto, distribui controles entre instrução, identidade, acesso, aplicação e operação. O modelo recebe apenas a autonomia necessária para sua função. A organização não depende de ele se lembrar de todas as obrigações quando pode transformar parte delas em limites técnicos verificáveis.
Valores do fornecedor e valores da organização podem divergir
O código da Microsoft AI reconhece que modelos servem a várias partes e precisam resolver tensões entre objetivos. Essa pluralidade também aparece na empresa. Uma área busca agilidade, outra protege dados, uma terceira responde pela experiência do cliente e outra precisa cumprir deveres profissionais ou regulatórios.
Divergência não significa necessariamente que alguém esteja errado. Uma mensagem comercial pode ser útil e ainda usar um dado fora da finalidade esperada. Uma recomendação pode parecer eficiente e reduzir a possibilidade de contestação. Uma automação pode seguir o pedido do usuário e ultrapassar a autoridade que a organização pretendia conceder.
A regra local deve antecipar conflitos frequentes e declarar precedências. Privacidade pode limitar personalização. Segurança pode impedir conveniência. Um dever profissional pode exigir revisão mesmo quando a saída parece correta. Quando a precedência só é decidida durante o incidente, a organização descobre tarde demais qual valor realmente governava o sistema.
O que o modelo recusa e o que a empresa não autoriza são conjuntos distintos
Restrições do desenvolvedor definem comportamentos que nenhum operador ou usuário deveria superar. Elas são uma base importante, mas não conhecem toda obrigação contratual, rotina interna, promessa de marca ou risco específico de uma organização.
Uma resposta pode ser permitida pelo modelo e ainda ser inadequada para o negócio. O sistema pode aceitar redigir uma oferta que a empresa não consegue cumprir, usar uma base acessível para uma finalidade não aprovada ou preparar uma alteração que exige separação entre quem propõe e quem executa. Não houve recusa porque a fronteira relevante pertence ao operador.
Por isso, a pergunta de governança não é apenas se o modelo fará algo perigoso em termos gerais. É também se a organização autorizou aquela ação naquele processo. Segurança do modelo e autorização empresarial se complementam, mas uma não substitui a outra.
Um documento aspiracional precisa ser tratado como promessa, não como evidência
A Microsoft AI descreve o código como norte para desenvolvimento futuro e reconhece lacunas entre os objetivos escritos e o comportamento dos modelos. Também afirma que palavras, por si só, não garantem alinhamento e que avaliações, testes e iteração serão necessários.
Essa ressalva é valiosa para compradores de tecnologia. Um princípio publicado mostra intenção e oferece critérios para diálogo, mas não prova desempenho em um caso empresarial. A organização precisa testar o sistema com seus documentos, idiomas, exceções, usuários, integrações e consequências.
O contrato de confiança deve ser construído com evidências específicas. A equipe preserva casos de referência, registra comportamentos indesejados, repete avaliações após mudanças relevantes e observa o uso real. A política declara o que se espera. A avaliação verifica se essa expectativa aparece onde importa.
Mudanças no código do fornecedor também são mudanças de dependência
O documento está aberto a consulta e deverá evoluir. Isso reforça a transparência, mas também lembra que a camada superior de comportamento pode mudar. Novas versões podem alterar padrões, interpretações, limites ou maneiras de responder a conflitos.
A empresa precisa saber quais processos dependem de determinado comportamento do modelo. Se uma aplicação pressupõe que o sistema sempre recusará uma ação, essa proteção não pode existir apenas como expectativa. Se depende de um formato, de uma explicação ou de uma forma de escalonamento, a dependência deve ser testada e monitorada.
O inventário de IA deve relacionar modelos e versões a processos, regras locais e casos de teste. Quando o fornecedor muda sua constituição ou o operador troca de modelo, a organização consegue identificar o que precisa ser reavaliado. Sem esse mapa, uma atualização externa pode modificar silenciosamente a política efetiva do negócio.
Política útil tem dono, versão e caminho de exceção
Uma política operacional precisa indicar quem pode alterá-la, quem aprova exceções e quem responde por decisões urgentes. Também deve ter versão e vigência. Caso contrário, equipes diferentes podem operar com expectativas incompatíveis enquanto acreditam seguir a mesma orientação.
Exceções merecem desenho próprio. Uma situação incomum não deve ser resolvida ampliando permanentemente a permissão do agente ou criando uma instrução informal. A exceção precisa ter justificativa, alcance, prazo, responsável e registro. Depois, a organização decide se ela revela uma regra nova ou permanece como caso isolado.
O caminho de interrupção completa o desenho. Pessoas afetadas e equipes operacionais precisam saber como contestar uma saída, suspender uma ação e encaminhar o caso. Controle humano não existe quando alguém percebe o problema, mas não possui autoridade ou canal para impedir a consequência.
O NIST coloca a responsabilidade dentro do ciclo de vida
O AI Risk Management Framework do NIST organiza a gestão em governar, mapear, medir e gerenciar. A função de governança atravessa as demais e pede políticas, papéis, responsabilidades, recursos, documentação e revisão ao longo do ciclo de vida.
Essa estrutura ajuda a transformar a cadeia de comando em rotina empresarial. Mapear conecta o uso ao contexto e às pessoas afetadas. Medir confronta comportamento com critérios definidos. Gerenciar escolhe respostas, limites e prioridades. Governar mantém responsáveis e decisões visíveis quando o sistema muda.
O ponto não é produzir um documento mais longo do que o código do fornecedor. É criar um conjunto menor de regras que realmente determine como a aplicação pode operar. Uma política curta, ligada a controles e evidências, protege melhor do que princípios amplos que ninguém consegue localizar na execução.
Cinco perguntas transformam a constituição em regra de negócio
Antes de liberar uma aplicação, a liderança pode começar com cinco perguntas. Qual resultado legítimo justifica o uso? Que dados e ferramentas são estritamente necessários? Quais ações o sistema pode executar sem confirmação? Que consequência exige revisão ou bloqueio? Quem pode interromper e decidir a retomada?
As respostas devem aparecer em mais de um lugar. Entram na descrição do processo, nas permissões técnicas, nos testes, nos registros e na capacitação das pessoas. Se uma resposta muda, a alteração precisa alcançar todas essas camadas para que política declarada e política executada continuem alinhadas.
Esse exercício também revela quando a organização ainda não está pronta. Se ninguém consegue definir o resultado, a fronteira de dados ou o responsável pela exceção, a ausência não deve ser preenchida pelo comportamento padrão do modelo. É um sinal para reduzir o escopo até que a decisão empresarial exista.
Conclusão
O Código de Conduta da Microsoft AI oferece uma referência pública para comportamentos, valores e limites pretendidos. Sua cadeia de comando reconhece algo essencial: entre a constituição do modelo e a preferência do usuário existe o operador, com conhecimento de contexto e responsabilidade por suas escolhas.
Para a empresa, esse lugar não pode ser ocupado apenas por um prompt ou por termos genéricos de uso responsável. Ele exige finalidade clara, permissões proporcionais, precedências, avaliações próprias, versões, exceções e autoridade real para interromper. Também exige reconhecer que intenção publicada pelo fornecedor não é prova de comportamento no processo local.
Na minha visão, uma organização demonstra maturidade quando consegue dizer não apenas quais valores espera da IA, mas como esses valores alteram uma permissão, um teste e uma decisão concreta. A regra ganha sentido quando alguém pode observá-la funcionando e contestá-la quando falha.
IA com propósito começa com bons princípios, mas só se sustenta quando eles atravessam a arquitetura e chegam à operação. O modelo pode ter sua constituição. A empresa continua responsável por escrever, aplicar e revisar as regras do mundo em que decidiu colocá-lo.