POLÍTICA DE INTELIGÊNCIA ARTIFICIAL, GOVERNANÇA E USO RESPONSÁVEL DE IA

IARA AI TECHNOLOGY CO.

Versão: 01/2026
Data da Aprovação: 28/09/2026
Revisão: no mínimo anual e sempre que houver alteração material tecnológica, regulatória, contratual ou de risco.

1. OBJETIVO

Esta Política estabelece os princípios, regras, responsabilidades, controles e critérios aplicáveis ao desenvolvimento, aquisição, integração, implementação, utilização, operação, monitoramento, evolução e descontinuação de sistemas de Inteligência Artificial utilizados pela IARA ou disponibilizados pela IARA a clientes, parceiros e terceiros.

A Política aplica-se a sistemas tradicionais de Inteligência Artificial, Machine Learning, Inteligência Artificial Generativa, Large Language Models (LLMs), modelos multimodais, modelos de visão, áudio e voz, embeddings, rerankers, sistemas de Retrieval-Augmented Generation (RAG), memória persistente, bases vetoriais, agentes de IA, sistemas multiagentes, ferramentas, conectores, APIs, MCP, sistemas de decisão assistida, automações inteligentes e demais tecnologias que utilizem modelos de IA para produzir conteúdo, recomendações, classificações, decisões ou executar ações.

A Política tem como objetivo assegurar que a IA seja utilizada pela IARA de forma legal, segura, transparente, responsável, auditável, controlável, proporcional ao risco e orientada ao resultado operacional, preservando a autoridade humana sobre decisões que envolvam direitos, obrigações, riscos materiais ou impactos relevantes sobre pessoas, empresas ou terceiros.

2. ABRANGÊNCIA

Esta Política aplica-se, conforme a natureza da atividade, a:

a) IARA AI Technology Co. e IARA AI Tecnologia Brasil Ltda.;
b) administradores, diretores, colaboradores, empregados, contratados e prestadores de serviços;
c) parceiros comerciais, tecnológicos e operacionais;
d) fornecedores de tecnologia, modelos, infraestrutura, dados e serviços de IA;
e) sistemas internos da IARA;
f) sistemas desenvolvidos, implantados ou operados para clientes;
g) AI Company Brain, AI Delivery Pods, AI Workflow, AI Operations System, RPO e demais produtos ou soluções que incorporem IA;
h) agentes individuais, sistemas multiagentes e orquestrações automatizadas;
i) modelos próprios, open-weight, modelos hospedados por terceiros e APIs de modelos;
j) integrações com sistemas externos, ferramentas, bancos de dados, CRMs, ERPs, plataformas corporativas, navegadores, serviços de busca, sistemas de comunicação e outras ferramentas capazes de receber ou produzir dados ou executar ações.

Quando incorporada por contrato, proposta, DPA, Termos de Uso, Playbook ou outro instrumento vinculante, esta Política também poderá estabelecer obrigações aplicáveis ao cliente ou terceiro contratante na extensão estabelecida pelo respectivo instrumento.

3. RELAÇÃO COM O SISTEMA DE GOVERNANÇA DA IARA

Esta Política integra o sistema de governança da IARA e deve ser interpretada conjuntamente com:

a) Código de Conduta Ética;
b) Política de Privacidade e Tratamento de Dados;
c) Política de Segurança da Informação;
d) Política de Prevenção e Combate à Lavagem de Dinheiro e Financiamento do Terrorismo;
e) Política de Aprovação de Vagas e Moderação da Plataforma;
f) Termos de Uso e Adesão aos Serviços;
g) Contratos de prestação de serviços, DPA e instrumentos específicos;
h) Contrato de Adesão ao Programa de Parceiros e Afiliados;
i) Playbooks operacionais;
j) demais políticas, procedimentos e padrões internos da IARA.

Esta Política não substitui as demais políticas e documentos. Ela estabelece os requisitos específicos de IA que complementam as regras de privacidade, segurança, compliance, contratação, operação e relacionamento da IARA.

Nenhuma disposição desta Política autoriza tratamento de dados, utilização de tecnologia ou execução de atividade que seja proibida pela legislação aplicável, por contrato válido ou por outra política obrigatória da IARA.

4. DEFINIÇÕES

Para fins desta Política:

IA ou Inteligência Artificial: sistema computacional capaz de produzir previsões, classificações, recomendações, conteúdo, decisões, ações ou outros resultados a partir de dados, modelos ou regras.

Modelo de IA: modelo estatístico, neural, generativo, multimodal ou de qualquer outra natureza utilizado para produzir inferências ou resultados.

LLM: Large Language Model ou modelo de linguagem de grande escala.

Agente de IA: sistema que utiliza um ou mais modelos para interpretar objetivos, planejar, decidir e/ou executar ações por meio de ferramentas, sistemas ou interfaces.

Sistema Multiagente: arquitetura composta por múltiplos agentes especializados que cooperam ou são coordenados para executar determinado objetivo.

Master Orchestrator: componente responsável pela compreensão contextual, planejamento, decomposição, coordenação e síntese de tarefas complexas dentro da arquitetura do AI Company Brain.

JEV Decision Fabric: camada de decisão delimitada e tipada utilizada para determinadas decisões estruturadas, retornando resultados controlados, tais como Choice, Score ou Null, com respectivos níveis de confiança ou probabilidades. O JEV não substitui o Master Orchestrator e não é, por si só, um agente conversacional ou orquestrador geral.

AI Company Brain: camada cognitiva de operação da empresa, que integra conhecimento, contexto operacional, memória, dados, decisões, agentes, ferramentas, sistemas, governança e observabilidade. O Brain não é um modelo individual, mas uma arquitetura de inteligência e controle.

RAG: Retrieval-Augmented Generation, arquitetura na qual dados ou documentos externos são recuperados para contextualizar uma inferência ou geração.

Memória: informações persistidas para permitir continuidade contextual, operacional ou comportamental de sistemas de IA.

Embedding: representação vetorial utilizada para busca semântica, recuperação ou comparação de informações.

Tool/Tool Use: capacidade de um agente utilizar uma função, API, banco de dados, navegador, sistema empresarial ou outro recurso externo.

MCP: Model Context Protocol ou outro protocolo equivalente de conexão entre modelos/agentes e ferramentas. Sua utilização não implica confiança automática no sistema conectado.

Dados do Cliente: dados fornecidos, produzidos ou acessados em razão dos serviços prestados ao cliente, incluindo dados operacionais, pessoais, confidenciais, prompts, contexto, memória, documentos, embeddings, outputs e metadados associados, conforme definido contratualmente.

Decisão de Alto Impacto: decisão que possa produzir efeito material sobre direitos, oportunidades, acesso a recursos, emprego, remuneração, crédito, saúde, serviços essenciais, segurança, obrigações jurídicas ou outras circunstâncias relevantes de uma pessoa ou organização.

5. PRINCÍPIOS DE GOVERNANÇA DE IA

A IARA adota os seguintes princípios:

5.1 Legalidade e conformidade

Sistemas de IA devem ser concebidos e operados de acordo com a legislação aplicável, contratos, políticas internas e requisitos regulatórios pertinentes.

5.2 Finalidade e proporcionalidade

A IA somente deverá acessar e processar dados, sistemas e recursos necessários para a finalidade aprovada.

5.3 Privacidade e proteção de dados desde a concepção

Privacidade e proteção de dados devem ser consideradas desde a arquitetura, seleção do modelo e desenho do fluxo, e não apenas após a implantação.

5.4 Segurança desde a concepção

Segurança, controle de acesso, isolamento, monitoramento, recuperação e resposta a incidentes devem integrar a arquitetura desde o início.

5.5 Autoridade humana

A IARA poderá automatizar execução, coordenação e trabalho operacional sem necessariamente automatizar a autoridade final sobre decisões relevantes.

A capacidade de uma IA executar uma ação não significa que ela esteja autorizada a decidir realizá-la.

5.6 Autonomia delimitada

Todo agente deverá possuir escopo, permissões, ferramentas, limites, condições de escalonamento e mecanismos de interrupção compatíveis com seu risco.

5.7 Transparência

Usuários devem ser informados quando estiverem interagindo diretamente com IA ou quando essa informação for relevante para a compreensão do processo ou do resultado.

5.8 Rastreabilidade

Decisões, inferências, ações relevantes e mudanças de configuração devem ser observáveis e, quando necessário, auditáveis.

5.9 Confiabilidade e incerteza

Resultados produzidos por IA são probabilísticos e podem conter erros, omissões, alucinações ou interpretações inadequadas. A criticidade do uso determina o grau de validação necessário.

5.10 Não discriminação

Sistemas de IA não deverão ser configurados ou utilizados para discriminar pessoas ou grupos de forma ilícita ou incompatível com os princípios e políticas da IARA.

5.11 Segurança de terceiros e cadeia tecnológica

Modelos, bibliotecas, datasets, APIs, ferramentas, plugins, conectores e fornecedores devem ser tratados como componentes da cadeia de risco.

5.12 Continuidade e reversibilidade

Quanto maior o impacto potencial de uma ação, maior deve ser a capacidade de interrompê-la, revertê-la ou operar em contingência.

5.13 Independência tecnológica

Sempre que tecnicamente e economicamente adequado, a IARA deverá evitar dependência desnecessária de um único modelo ou fornecedor, mantendo arquitetura de abstração e possibilidade de substituição.

6. ARQUITETURA DE IA DA IARA

A arquitetura de IA da IARA deverá distinguir claramente entre:

Modelos → Orquestração → Agentes → Ferramentas → Dados/Memória → Sistemas → Governança → Observabilidade.

O modelo não é a arquitetura.

A IARA poderá utilizar múltiplos modelos simultaneamente, atribuindo diferentes funções de acordo com capacidade, custo, latência, segurança, contexto, modalidade, confiabilidade, disponibilidade e requisitos do caso de uso.

O AI Company Brain deverá ser concebido como uma Cognitive Operating Layer / Control Plane Cognitivo, posicionada acima dos modelos, agentes, ferramentas e sistemas de terceiros.

Quando aplicável, a arquitetura poderá incluir:

a) Master Orchestrator para compreensão, planejamento, decomposição e síntese;
b) JEV Decision Fabric para decisões delimitadas e estruturadas;
c) agentes especializados;
d) RAG e mecanismos de recuperação;
e) memória corporativa;
f) bases vetoriais e mecanismos de busca;
g) APIs e integrações;
h) políticas determinísticas e gates de decisão;
i) observabilidade e auditoria;
j) mecanismos de fallback e continuidade.

Nenhum modelo individual deverá ser considerado autoridade absoluta sobre o funcionamento do sistema.

7. CLASSIFICAÇÃO DE RISCO DE SISTEMAS DE IA

Todo sistema de IA relevante deverá receber classificação de risco antes da utilização em produção.

Nível 1 — Assistivo

Aplicações predominantemente informacionais, criativas ou administrativas, sem execução material automática.

Exemplos:

• resumo;

• tradução;

• elaboração de rascunhos;

• classificação não material;

• brainstorming;

• apoio à pesquisa.

Pode operar com supervisão simplificada, desde que não receba dados incompatíveis com a classificação de segurança.

Nível 2 — Operacional

Sistemas que executam tarefas ou ações, desde que limitadas, reversíveis e dentro de escopo controlado.

Exemplos:

• atualização de CRM;

• preparação de relatórios;

• triagem;

• classificação operacional;

• criação de tickets;

• automações internas;

• atualização de registros.

Exige permissões delimitadas, logs e mecanismos de interrupção.

Nível 3 — Decisão Material Assistida

Sistemas que influenciam decisões relevantes ou executam operações com impacto econômico, contratual, profissional ou operacional significativo.

Exemplos:

• priorização comercial relevante;

• aprovação de pagamentos;

• decisões de crédito;

• recomendação de contratação;

• avaliação de fornecedores críticos;

• decisões que alterem significativamente processos ou recursos.

Exige validação humana substantiva e controles adicionais.

Nível 4 — Alto Impacto ou Crítico

Sistemas associados a decisões ou ações que possam produzir efeitos graves, relevantes, irreversíveis ou de difícil reversão.

Exemplos incluem decisões relacionadas a:

• emprego e rejeição de candidatos;

• remuneração ou benefícios;

• crédito ou acesso financeiro;

• saúde;

• direitos jurídicos;

• segurança física;

• alteração de privilégios críticos;

• movimentação financeira relevante;

• contratação ou rescisão de obrigações materiais;

• exclusão definitiva de dados ou ativos críticos;

• execução autônoma de ações irreversíveis.

Nesses casos, a IA não poderá constituir a única autoridade decisória, salvo hipótese expressamente autorizada por avaliação jurídica, regulatória, contratual e de risco específica.

8. DECISÃO E AUTORIZAÇÃO HUMANA

A IARA adota como regra operacional:

Automatizar execução não significa automatizar autoridade.

Em sistemas de maior risco, o responsável humano deve ter capacidade real de:

a) compreender o resultado relevante;
b) acessar informações suficientes para sua avaliação;
c) questionar ou rejeitar a recomendação;
d) solicitar revisão;
e) interromper a execução;
f) assumir a decisão;
g) registrar a decisão quando necessário.

A revisão humana não deverá ser reduzida a uma formalidade ou aprovação automática.

Para operações críticas, a arquitetura poderá exigir:

• aprovação explícita;

• dupla autorização;

• limites financeiros;

• confirmação adicional;

• segregação de funções;

• sandbox;

• execução em etapas;

• reversão automática;

• circuit breaker;

• kill switch.

No recrutamento, em particular, a IA poderá executar screening, triagem, análise e preparação de informações, mas a decisão de contratação permanecerá com a empresa contratante, respeitadas as regras específicas do serviço e da legislação aplicável.

9. DADOS, PRIVACIDADE E MEMÓRIA

Todo fluxo de IA deverá ser analisado segundo a cadeia:

Dados → Finalidade → Controlador → Operador → Suboperadores → Modelo → Armazenamento → Retenção → Acesso → Exclusão.

Esse mapa deverá ser estabelecido antes de operações relevantes com dados pessoais ou confidenciais.

Para fins de IA, devem ser considerados dados não apenas os documentos originais, mas também:

a) prompts;
b) system prompts quando aplicáveis;
c) contexto enviado ao modelo;
d) respostas;
e) memória;
f) embeddings;
g) bases vetoriais;
h) documentos recuperados via RAG;
i) traces;
j) logs;
k) metadados;
l) avaliações;
m) datasets de fine-tuning;
n) dados utilizados para avaliação ou testes.

9.1 Isolamento de clientes

Dados de clientes distintos não poderão ser misturados em memória, RAG, embeddings, contexto, treinamento ou qualquer mecanismo que permita que um cliente tenha acesso indevido às informações de outro.

A segregação poderá ser implementada por tenant, banco, índice, namespace, chave, credencial, ambiente ou outro mecanismo tecnicamente adequado ao risco.

9.2 Memória corporativa

A memória do AI Company Brain deverá possuir:

a) finalidade definida;
b) origem identificável;
c) controle de acesso;
d) política de retenção;
e) possibilidade de correção;
f) possibilidade de exclusão quando aplicável;
g) controle de versionamento;
h) mecanismos para impedir escrita indiscriminada por agentes.

Informação gerada por IA não deverá ser automaticamente promovida a conhecimento corporativo confiável.

9.3 Dados confidenciais

Dados classificados como confidenciais ou sensíveis somente poderão ser enviados a modelos ou provedores expressamente aprovados para aquela categoria de informação.

É proibido utilizar planos gratuitos, contas pessoais ou ferramentas de IA não aprovadas para processar dados confidenciais da IARA ou de clientes.

10. TREINAMENTO, FINE-TUNING E MELHORIA DE MODELOS

A IARA adota como regra geral:

Dados de clientes não serão utilizados para treinar, fine-tunar ou melhorar modelos compartilhados de terceiros ou modelos compartilhados da IARA sem autorização específica, base jurídica adequada e aprovação correspondente.

Isso inclui, conforme o caso:

• prompts;

• documentos;

• memória;

• RAG;

• embeddings;

• outputs;

• traces;

• logs;

• avaliações;

• dados operacionais;

• datasets derivados.

O fato de um dado não conter informação pessoal não significa automaticamente que ele possa ser utilizado para treinamento. Direitos contratuais, confidencialidade, propriedade intelectual e restrições de uso também deverão ser considerados.

10.1 Dados sintéticos e anonimizados

A IARA poderá utilizar dados sintéticos, anonimizados ou devidamente desidentificados para desenvolvimento, avaliação e melhoria, desde que a técnica empregada seja adequada à finalidade e não permita reidentificação indevida.

10.2 Fine-tuning

Fine-tuning com dados de clientes exige:

a) finalidade definida;
b) origem e direitos sobre os dados;
c) análise de segurança;
d) análise de privacidade;
e) autorização correspondente;
f) mecanismo de eliminação ou substituição quando aplicável;
g) documentação do dataset;
h) avaliação do modelo resultante.

11. SELEÇÃO E GOVERNANÇA DE MODELOS E PROVEDORES

A unidade de aprovação da IARA não será apenas o “nome do modelo”.

A unidade real de aprovação será:

Fornecedor + família/modelo + modalidade de implantação + endpoint + plano/tier + região + configuração de dados + retenção + finalidade.

Um mesmo modelo poderá ter classificações diferentes dependendo desses fatores.

11.1 Categorias de modelos

A IARA poderá utilizar:

Modelos comerciais fechados

Incluindo, entre outros:

• OpenAI GPT;

• Anthropic Claude;

• Google Gemini;

• xAI Grok;

• Mistral;

• Cohere;

• outros modelos comerciais aprovados.

Modelos open-weight ou self-hosted

Incluindo, entre outros:

• Qwen;

• Llama;

• DeepSeek;

• GLM;

• Mistral;

• outros modelos compatíveis com implantação controlada.

Modelos e serviços especializados

Incluindo:

• Perplexity;

• Exa;

• AssemblyAI;

• modelos de visão;

• modelos de embeddings;

• rerankers;

• modelos de speech-to-text e text-to-speech;

• sistemas especializados de pesquisa ou recuperação.

Modelos asiáticos e alternativas multi-provider

A IARA poderá utilizar modelos como:

• Kimi, da Moonshot AI;

• GLM, da Z.ai/Zhipu;

• Qwen, da Alibaba Cloud;

• DeepSeek;

• Yi;

• outros modelos chineses, asiáticos ou open-weight que atendam aos critérios desta Política.

Nenhum fornecedor será considerado automaticamente aprovado apenas por sua reputação, tamanho ou capacidade técnica.

12. REGISTRO DE MODELOS E PROVEDORES

A IARA deverá manter um Registro de Modelos e Provedores de IA, atualizado conforme a evolução da arquitetura.

O registro deverá conter, quando aplicável:

O registro deverá ser tratado como documento operacional vivo.

A Política não deverá depender de informações estáticas sobre retenção ou treinamento de fornecedores que possam mudar sem alteração da Política.

13. CRITÉRIOS PARA APROVAÇÃO DE PROVEDORES

Antes de utilizar um novo provedor com dados da IARA ou de clientes, deverão ser considerados, conforme o risco:

a) finalidade e caso de uso;
b) política de treinamento;
c) retenção de inputs e outputs;
d) armazenamento de arquivos;
e) localização dos dados;
f) transferência internacional;
g) DPA e termos comerciais;
h) subprocessadores;
i) controles de segurança;
j) criptografia;
k) isolamento de clientes;
l) mecanismos de exclusão;
m) gestão de incidentes;
n) disponibilidade;
o) versionamento e depreciação de modelos;
p) limitações de uso;
q) propriedade intelectual;
r) capacidade de auditoria;
s) requisitos regulatórios específicos;
t) capacidade de substituição por outro modelo.

O uso de uma versão consumer de um serviço não deverá ser presumido equivalente à utilização de uma API ou oferta Enterprise.

14. PROVEDORES E MODELOS: REGRA ESPECÍFICA

Modelos como Kimi, GLM, Qwen, DeepSeek, Claude, GPT, Gemini, Mistral, Llama, Grok e outros poderão ser incorporados à arquitetura da IARA conforme sua classificação no Registro de Modelos e Provedores.

A aprovação deverá ocorrer por implantação e caso de uso, e não simplesmente por família de modelo.

Particular atenção deverá ser dada a:

a) processamento internacional;
b) retenção;
c) treinamento ou melhoria pelo fornecedor;
d) uso de dados para segurança/abuse monitoring;
e) limites específicos do modelo;
f) restrições regulatórias do fornecedor;
g) capacidade de processamento de dados confidenciais;
h) uso em decisões de alto impacto.

Modelos que imponham restrições contratuais incompatíveis com determinado caso de uso não deverão ser utilizados nesse caso, mesmo que tecnicamente sejam capazes de executá-lo.

15. CUSTOMER-CONFIGURED AI E INTEGRAÇÕES EXTERNAS

Clientes poderão, quando permitido pelo produto e contrato, integrar ferramentas externas de IA à arquitetura da IARA.

Nesses casos:

a) a ferramenta deverá ser identificada;
b) os dados compartilhados deverão estar definidos;
c) as permissões deverão ser limitadas;
d) as políticas de privacidade e retenção do terceiro deverão ser avaliadas quando aplicável;
e) configurações de treinamento e melhoria deverão ser desabilitadas quando exigido;
f) a integração deverá ser registrada;
g) acessos deverão ser revogados quando a integração deixar de ser necessária.

A IARA não considerará um terceiro confiável apenas porque utiliza o protocolo MCP, API, OAuth ou qualquer outro padrão de integração.

O protocolo de conexão não substitui a avaliação de segurança e governança.

16. AGENTES DE IA

Todo agente de IA utilizado em produção deverá possuir, no mínimo:

a) identificação única;
b) finalidade;
c) responsável;
d) modelo ou modelos utilizados;
e) ferramentas autorizadas;
f) sistemas acessíveis;
g) permissões;
h) limites de execução;
i) critérios de escalonamento;
j) mecanismos de interrupção;
k) requisitos de aprovação humana;
l) critérios de sucesso;
m) mecanismos de observabilidade.

16.1 Least privilege

Agentes devem receber somente as permissões necessárias para executar sua finalidade.

Não deverá ser concedido a um agente acesso amplo apenas porque a arquitetura atual não oferece mecanismo de granularidade.

16.2 Ferramentas

Ferramentas não utilizadas deverão permanecer desabilitadas.

Quando possível, ações críticas deverão utilizar políticas determinísticas independentes do modelo.

Exemplo:

O modelo pode recomendar que um pagamento seja efetuado, mas o sistema de autorização deverá verificar valor, destinatário, limite, permissão, contexto e necessidade de aprovação antes da execução.

16.3 Credenciais

Credenciais, tokens, senhas e chaves privadas não deverão ser inseridos desnecessariamente em prompts ou contexto.

Sempre que possível, deverão ser utilizados mecanismos de identidade de serviço, vaults, tokens de curta duração e permissões específicas.

17. SEGURANÇA DE IA E AMEAÇAS ESPECÍFICAS

A arquitetura deve considerar, conforme aplicável, riscos como:

a) Prompt Injection;
b) Indirect Prompt Injection;
c) Sensitive Information Disclosure;
d) Data and Model Poisoning;
e) Supply Chain Attacks;
f) Improper Output Handling;
g) Excessive Agency;
h) Tool Misuse;
i) Privilege Abuse;
j) Goal Hijacking;
k) Unbounded Consumption;
l) Model Extraction;
m) Memory Poisoning;
n) Cross-Tenant Data Leakage;
o) Cascading Agent Failures;
p) Excessive Trust in AI Outputs.

Esses riscos deverão ser tratados de maneira proporcional ao risco do sistema.

Em arquiteturas agentic, a IARA deverá considerar especialmente que funcionalidade excessiva, permissões excessivas e autonomia excessiva podem ampliar significativamente o impacto de erros ou manipulações.

18. RAG, CONHECIMENTO E DATA POISONING

Fontes utilizadas por RAG devem ser avaliadas quanto à:

a) origem;
b) confiabilidade;
c) atualidade;
d) autorização de uso;
e) classificação de segurança;
f) controle de acesso;
g) integridade;
h) possibilidade de adulteração.

Conteúdo recuperado de fontes externas deverá ser considerado não confiável por padrão.

Documentos externos, páginas web, emails, tickets ou outros conteúdos poderão conter instruções maliciosas destinadas a manipular o agente.

Agentes não deverão interpretar conteúdo recuperado como autoridade de sistema sem validação adequada.

Fontes críticas deverão possuir mecanismos de:

• versionamento;

• provenance;

• validação;

• expiração;

• revisão;

• rollback;

• isolamento;

• monitoramento.

19. SAÍDAS, PRECISÃO E ALUCINAÇÕES

A IARA reconhece que sistemas de IA podem gerar:

• informações incorretas;

• conteúdo inventado;

• citações inexistentes;

• conclusões inadequadas;

• interpretações incompletas;

• resultados inconsistentes entre execuções.

Quanto maior o risco da aplicação, maior deverá ser o nível de validação exigido.

Para usos relevantes, poderão ser empregados:

a) recuperação de fontes;
b) citações;
c) regras determinísticas;
d) verificação cruzada;
e) segundo modelo;
f) avaliação humana;
g) testes de consistência;
h) thresholds de confiança;
i) rejeição automática quando a confiança for insuficiente.

O conhecimento de um modelo não deverá ser considerado equivalente a uma fonte atualizada.

Quando a atualidade da informação for essencial, o sistema deverá utilizar fontes ou ferramentas adequadas de recuperação de informação.

20. TRANSPARÊNCIA E INTERAÇÃO COM USUÁRIOS

Quando uma pessoa estiver interagindo diretamente com um sistema de IA e isso não for evidente pelo contexto, a IARA deverá fornecer identificação adequada.

Quando conteúdo produzido por IA for relevante para uma decisão ou comunicação externa, sua utilização deverá ser tratada de acordo com legislação, contrato e contexto.

A IARA não deverá apresentar como manifestação humana independente aquilo que, por lei, contrato ou circunstância relevante, deva ser identificado como conteúdo produzido ou assistido por IA.

Quando apropriado, sistemas deverão distinguir entre:

gerado por IA,
revisado por humano,
aprovado por humano,
executado automaticamente.

21. DECISÕES SIGNIFICATIVAS E SISTEMAS DE ALTO IMPACTO

A IARA não deverá utilizar IA como autoridade exclusiva para decisões de alto impacto sem avaliação jurídica, regulatória e de risco específica.

Isso inclui, entre outros contextos:

a) contratação ou rejeição profissional;
b) demissão;
c) definição de remuneração;
d) concessão ou negativa de crédito;
e) decisões médicas;
f) direitos ou obrigações jurídicas;
g) acesso a benefícios relevantes;
h) segurança física ou acesso privilegiado;
i) decisões financeiras materiais.

Em aplicações de recrutamento, a IA poderá apoiar o processo com screening, triagem, avaliação, pesquisa e organização de informações, mas a autoridade final sobre contratação deverá permanecer com o responsável designado pela empresa contratante, de acordo com o serviço contratado e os requisitos legais aplicáveis.

22. AVALIAÇÃO ANTES DA PRODUÇÃO

Sistemas de IA relevantes deverão ser avaliados antes de entrar em produção.

A avaliação deverá considerar, de acordo com o risco:

a) qualidade do resultado;
b) precisão;
c) robustez;
d) alucinação;
e) segurança;
f) prompt injection;
g) data poisoning;
h) vazamento de dados;
i) comportamento das ferramentas;
j) limites de autonomia;
k) viés e discriminação;
l) custo;
m) latência;
n) disponibilidade;
o) degradação;
p) comportamento sob entradas adversariais;
q) falhas de integração.

Modelos de maior risco deverão passar por testes adversariais e avaliação específica antes de sua utilização em produção.

23. AVALIAÇÃO CONTÍNUA

A avaliação não termina com o go-live.

Deverão ser monitorados, conforme aplicável:

• qualidade;

• taxa de erro;

• confiança;

• incidentes;

• violações de política;

• tool calls;

• custo;

• latência;

• consumo;

• disponibilidade;

• comportamento dos agentes;

• qualidade das fontes;

• mudanças de modelo;

• mudanças de dados;

• mudanças de contexto;

• feedback humano.

Mudança relevante de modelo ou fornecedor poderá exigir nova homologação.

24. MUDANÇA, ATUALIZAÇÃO E DEPRECIAÇÃO DE MODELOS

A IARA reconhece que fornecedores podem:

a) atualizar modelos;
b) substituir versões;
c) alterar comportamento;
d) modificar APIs;
e) alterar preços;
f) modificar regiões;
g) mudar políticas de retenção;
h) descontinuar modelos.

Sempre que tecnicamente viável, a arquitetura deverá manter camada de abstração que permita substituição de modelo sem reconstrução completa do sistema.

Mudanças materiais deverão ser avaliadas quanto a:

• segurança;

• comportamento;

• qualidade;

• custo;

• privacidade;

• conformidade;

• compatibilidade;

• risco operacional.

25. CONTINUIDADE E FALLBACK

Sistemas de IA críticos deverão possuir, conforme a análise de risco:

a) modelo alternativo;
b) fornecedor alternativo;
c) modo manual;
d) fila de reprocessamento;
e) retry controlado;
f) circuit breaker;
g) limites de consumo;
h) procedimento de contingência.

A dependência de um único fornecedor não deverá ser considerada aceitável para processos cuja interrupção possa gerar impacto material sem avaliação e aprovação correspondente.

26. OBSERVABILIDADE E AUDITORIA

Observabilidade é parte da governança do sistema de IA.

Quando tecnicamente e juridicamente apropriado, deverão ser registrados:

a) modelo e versão;
b) agente responsável;
c) versão de prompt ou policy relevante;
d) ferramentas utilizadas;
e) ações executadas;
f) autorização humana;
g) timestamp;
h) origem relevante dos dados;
i) resultado;
j) erro ou exceção;
k) decisão de fallback;
l) alteração de configuração.

A quantidade e o conteúdo dos logs deverão respeitar minimização, finalidade, classificação de segurança e requisitos de privacidade.

Nem todo prompt ou output precisa ser armazenado integralmente apenas porque tecnicamente é possível fazê-lo.

27. RETENÇÃO

A retenção de dados relacionados à IA deverá ser definida segundo:

a) finalidade;
b) necessidade operacional;
c) legislação;
d) contrato;
e) segurança;
f) obrigações de auditoria;
g) requisitos do fornecedor;
h) política de retenção da IARA.

Não haverá uma regra universal de retenção para todos os provedores.

Quando um terceiro possuir período de retenção próprio, esse período deverá constar do Registro de Modelos e Provedores.

A IARA deverá evitar retenção indefinida de:

• prompts;

• outputs;

• arquivos;

• memória;

• embeddings;

• traces;

• logs.

28. INCIDENTES DE IA

São considerados incidentes de IA, entre outros:

a) vazamento de dados através de modelo;
b) acesso indevido entre clientes;
c) execução não autorizada de ferramenta;
d) prompt injection bem-sucedido;
e) alteração maliciosa de memória;
f) data poisoning relevante;
g) saída potencialmente danosa;
h) bypass de controle;
i) uso de modelo ou ferramenta não autorizados;
j) comprometimento de fornecedor;
k) falha de autenticação;
l) abuso de privilégios;
m) comportamento inesperado de agente;
n) falha em cadeia entre agentes ou sistemas.

Incidentes que também constituam incidente de segurança da informação ou proteção de dados deverão seguir os procedimentos e prazos estabelecidos na Política de Segurança da Informação, contratos e legislação aplicável.

Colaboradores e terceiros deverão comunicar imediatamente incidentes relevantes. Quando aplicável aos incidentes de segurança definidos pela governança da IARA, deverá ser observado o prazo interno estabelecido de comunicação.

29. USOS PROIBIDOS

É proibido utilizar sistemas de IA da IARA para:

a) atividades ilícitas;
b) fraude;
c) lavagem de dinheiro ou financiamento do terrorismo;
d) evasão de sanções ou controles legais;
e) discriminação ilegal;
f) assédio, ameaça ou perseguição;
g) obtenção indevida de credenciais ou segredos;
h) exfiltração de dados;
i) invasão de sistemas;
j) contorno deliberado de mecanismos de segurança;
k) treinamento não autorizado de modelos com dados protegidos;
l) mistura deliberada de dados de clientes;
m) falsificação de evidências;
n) manipulação ilícita de pessoas;
o) uso de IA como decisão exclusiva em aplicações de alto impacto sem aprovação específica;
p) qualquer uso expressamente vedado por legislação, contrato, política interna ou pelos termos do respectivo fornecedor.

A IARA poderá suspender agentes, integrações, usuários ou serviços quando houver risco relevante de violação desta Política.

30. PROPRIEDADE INTELECTUAL

A utilização de IA não altera automaticamente os direitos de propriedade intelectual sobre:

a) dados do cliente;
b) documentos;
c) modelos;
d) prompts;
e) workflows;
f) código;
g) arquiteturas;
h) metodologias;
i) outputs.

A titularidade ou licença dos desenvolvimentos deverá observar o contrato específico aplicável.

Frameworks, metodologias, componentes genéricos, conhecimento técnico e ativos preexistentes da IARA permanecerão sujeitos às regras de propriedade intelectual estabelecidas no instrumento contratual correspondente.

A utilização de conteúdo externo, datasets, modelos ou componentes open-source deverá respeitar as respectivas licenças e restrições de uso.

31. RESPONSABILIDADES DOS CLIENTES

Quando a IARA atuar como prestadora, operadora ou fornecedora de uma solução de IA:

a) a responsabilidade de cada Parte será definida pelo contrato aplicável;
b) o cliente deverá fornecer informações e instruções necessárias;
c) o cliente deverá assegurar que possui autorização para disponibilizar os dados utilizados;
d) decisões que permaneçam sob sua autoridade deverão continuar sob sua responsabilidade;
e) configurações de ferramentas externas feitas diretamente pelo cliente deverão observar esta Política e os requisitos contratuais aplicáveis;
f) o cliente não deverá utilizar a solução para finalidades incompatíveis com sua contratação ou com a legislação aplicável.

A IARA poderá recusar instruções que criem risco jurídico, de segurança, privacidade, compliance ou reputacional incompatível com esta Política.

32. RESPONSABILIDADES DOS PARCEIROS E FORNECEDORES

Parceiros e fornecedores que tenham acesso a sistemas ou dados de IA da IARA deverão:

a) utilizar somente os recursos autorizados;
b) observar esta Política e os documentos incorporados por contrato;
c) proteger dados e credenciais;
d) não utilizar dados da IARA ou clientes para finalidades próprias não autorizadas;
e) não inserir dados em serviços de IA externos sem autorização;
f) comunicar incidentes;
g) observar requisitos de confidencialidade e LGPD;
h) manter mecanismos de controle sobre subcontratados e suboperadores quando aplicável.

33. GOVERNANÇA, RESPONSABILIDADES INTERNAS E APROVAÇÕES

Diretoria

A Diretoria deverá:

a) estabelecer direção e apetite de risco;
b) aprovar esta Política;
c) aprovar exceções relevantes;
d) assegurar recursos proporcionais ao risco da operação.

Responsável por Governança de IA

O responsável designado pela IARA deverá coordenar:

a) registro de sistemas;
b) registro de modelos;
c) classificação de risco;
d) avaliação de novos usos;
e) gestão de exceções;
f) revisão da Política;
g) articulação entre tecnologia, segurança, privacidade, jurídico, compliance e operação.

Tecnologia e Engenharia

Deverão:

a) implementar controles técnicos;
b) gerir modelos, agentes e ferramentas;
c) manter versionamento;
d) implementar testes;
e) controlar acessos;
f) manter observabilidade;
g) manter mecanismos de contingência.

Privacidade/LGPD

Deverá participar das avaliações envolvendo dados pessoais, definição de papéis de controlador/operador, bases legais, transferências internacionais, retenção e direitos dos titulares.

Segurança da Informação

Deverá avaliar riscos de segurança, controles de acesso, criptografia, incidentes, fornecedores, vulnerabilidades, cadeia de software e arquitetura.

Jurídico/Compliance

Deverá ser envolvido em casos que apresentem:

a) risco regulatório relevante;
b) decisão de alto impacto;
c) direitos de titulares;
d) propriedade intelectual;
e) questões contratuais;
f) sanções;
g) atividades financeiras reguladas;
h) PLD/FT;
i) conflito de interesses ou risco reputacional relevante.

Operação

O responsável operacional pelo processo continua responsável pelos resultados e pela execução dos controles humanos definidos para o processo.

34. EXCEÇÕES

Exceções a esta Política deverão ser documentadas e, conforme o nível de risco, conter:

a) justificativa;
b) finalidade;
c) sistema afetado;
d) dados envolvidos;
e) riscos identificados;
f) controles compensatórios;
g) responsável;
h) prazo de validade;
i) condição de encerramento.

Exceções não poderão autorizar finalidade ilegal, violação deliberada de direitos ou bypass intencional de requisitos legais.

Exceções deverão possuir prazo definido e ser reavaliadas.

35. TREINAMENTO E CONSCIENTIZAÇÃO

Pessoas com acesso a sistemas de IA da IARA deverão receber orientação compatível com suas responsabilidades.

O treinamento deverá contemplar, conforme a função:

• utilização segura de IA;

• dados confidenciais;

• LGPD;

• segurança;

• prompt injection;

• data poisoning;

• outputs incorretos;

• uso de ferramentas;

• agentes;

• memória;

• políticas dos provedores;

• incidentes;

• limites de autoridade.

O acesso a ferramentas de maior risco poderá depender de treinamento específico e autorização.

36. REVISÃO DA POLÍTICA

Esta Política deverá ser revisada, no mínimo, anualmente.

A revisão poderá ocorrer antes do prazo quando houver:

a) mudança relevante na legislação;
b) mudança relevante na arquitetura da IARA;
c) adoção de novos tipos de agentes;
d) novo modelo ou fornecedor relevante;
e) incidente significativo;
f) mudança contratual relevante;
g) alteração material no perfil de risco;
h) evolução substancial da tecnologia.

37. REFERÊNCIAS NORMATIVAS E TÉCNICAS

A IARA utiliza como referências, conforme aplicabilidade:

• Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD);

• Marco Civil da Internet;

• regulamentações e orientações aplicáveis da ANPD;

• legislação brasileira aplicável às atividades da IARA;

• legislação estrangeira aplicável às operações internacionais;

• EU AI Act, quando aplicável;

• ISO/IEC 42001 — Artificial Intelligence Management System;

• ISO/IEC 23894 — Guidance on AI Risk Management;

• NIST AI Risk Management Framework;

• NIST Generative AI Profile;

• OWASP Top 10 for LLM Applications;

• OWASP Top 10 for Agentic Applications;

• políticas, termos e requisitos dos fornecedores de modelos e serviços de IA utilizados pela IARA.

A referência a qualquer norma ou framework nesta Política não significa que a IARA esteja certificada ou formalmente enquadrada em determinado regime, salvo declaração específica nesse sentido.

38. DISPOSIÇÕES FINAIS

O desenvolvimento tecnológico da IARA não deverá depender da existência de uma única tecnologia, modelo ou fornecedor.

A IARA poderá substituir modelos, fornecedores, frameworks ou componentes técnicos quando isso melhorar segurança, desempenho, disponibilidade, custo, privacidade, conformidade ou capacidade operacional.

A arquitetura deverá, sempre que possível, separar:

inteligência do modelo
de
governança do sistema
de
autoridade da operação.

Nenhum modelo individual, agente ou fornecedor poderá ser tratado como autoridade irrestrita sobre os sistemas da IARA.

A confiança em IA deverá resultar de arquitetura, controles, avaliação, supervisão, observabilidade e governança, e não apenas da capacidade declarada de um modelo.

A IARA poderá evoluir continuamente sua arquitetura multi-modelo, incluindo modelos comerciais, open-weight, self-hosted e especializados, desde que cada componente seja submetido aos critérios desta Política e ao Registro de Modelos e Provedores.

ANEXO I — CLASSIFICAÇÃO OPERACIONAL DE MODELOS

A IARA utilizará as seguintes categorias operacionais:

ANEXO II — EXEMPLOS DE ECOSSISTEMA DE MODELOS

O ecossistema técnico da IARA poderá incluir, entre outros:

OpenAI: GPT e modelos especializados.
Anthropic: Claude.
Google: Gemini.
Moonshot AI: Kimi.
Z.ai/Zhipu: GLM.
Alibaba Cloud: Qwen.
DeepSeek: DeepSeek.
Mistral AI: Mistral.
Meta: Llama.
xAI: Grok.
Cohere: modelos especializados e enterprise.
Perplexity: pesquisa e recuperação.
Exa: busca e pesquisa.
AssemblyAI: speech-to-text e serviços de áudio.
AWS/Bedrock: infraestrutura e acesso empresarial a modelos compatíveis.

A inclusão de um modelo nesta lista não constitui aprovação automática para qualquer finalidade.

A aprovação depende da versão, fornecedor, modalidade de acesso, região, contrato, configuração de dados e classificação de risco.

ANEXO III — ESTADOS DE APROVAÇÃO

Cada modelo, provedor ou ferramenta deverá ser classificado como:

APROVADO
Pode ser utilizado para os casos de uso e categorias de dados especificados no Registro.

CONDICIONAL
Pode ser utilizado somente nas condições especificadas no Registro.

RESTRITO
Pode ser utilizado apenas em ambientes, casos de uso ou categorias de dados expressamente autorizados.

BLOQUEADO
Não pode ser utilizado pela IARA para fins corporativos ou de clientes.

A alteração de status deverá ser registrada.

ANEXO IV — GATE MÍNIMO PARA NOVO SISTEMA DE IA

Antes do go-live, o responsável deverá responder:

1. Qual problema operacional o sistema resolve?

2. Qual é a finalidade exata?

3. Qual é o nível de risco?

4. Quais dados serão processados?

5. Qual é a classificação de segurança?

6. Quem é controlador e quem é operador?

7. Qual modelo será utilizado?

8. Qual provedor será utilizado?

9. Onde os dados serão processados?

10. Qual é a política de treinamento do fornecedor?

11. Qual é a retenção?

12. Quais subprocessadores participam?

13. Quais ferramentas o agente pode acessar?

14. Quais permissões possui?

15. Quais ações exigem aprovação humana?

16. Como funciona o fallback?

17. Como o sistema é interrompido?

18. Como as ações são registradas?

19. Como serão tratados prompt injection e data poisoning?

20. Como memória e RAG serão isolados?

21. Como serão tratados erros e alucinações?

22. Como será realizada a avaliação antes do go-live?

23. Como será monitorado após o go-live?

24. O que acontece quando o modelo for atualizado ou descontinuado?

25. Existe mecanismo para retirada ou exclusão dos dados?

ANEXO V — PRINCÍPIO DE ARQUITETURA IARA

A arquitetura de IA da IARA deverá buscar preservar a seguinte separação:

MODELOS
produzem inteligência computacional.

MASTER ORCHESTRATOR
compreende, planeja, decompõe e coordena.

JEV DECISION FABRIC
delimita e estrutura determinadas decisões.

AGENTS
executam funções especializadas.

TOOLS / APIs / SISTEMAS
realizam ações no mundo operacional.

MEMORY / RAG / KNOWLEDGE
fornecem contexto corporativo.

GOVERNANCE
define limites, responsabilidades e permissões.

OBSERVABILITY
registra, mede e permite auditar.

HUMANS
mantêm autoridade sobre decisões e exceções relevantes.

A IARA não considera que adicionar mais modelos ou agentes, isoladamente, constitua uma arquitetura de IA madura.

Maturidade está na capacidade de compreender, decidir, executar, controlar, observar, corrigir e evoluir com segurança e responsabilidade.