# Modelo de política interna de inteligência artificial

Versão: 1.0  
Data do modelo: 25/08/2026  
Owner do documento: [função ou nome]  
Aprovado por: [órgão ou função]  
Próxima revisão: [data]  

> Este modelo ajuda a tomar decisões internas. Não é aconselhamento jurídico, não certifica conformidade e deve ser adaptado ao contexto, aos sistemas e ao risco da organização.

## 1. Objetivo e âmbito

Esta política define como [organização] propõe, avalia, aprova, utiliza, monitoriza e termina sistemas de IA.

Aplica-se a:

- trabalhadores, prestadores e parceiros que utilizem IA em nome da organização;
- sistemas comprados, configurados ou desenvolvidos internamente;
- funcionalidades de IA incorporadas em software existente;
- testes, pilotos e utilizações em produção.

Fora do âmbito: [listar exclusões justificadas].

## 2. Princípios de decisão

1. Existe um problema e um owner antes de existir uma ferramenta.
2. Dados e conteúdos só são usados quando existe autorização e finalidade compatível.
3. O nível de controlo aumenta com o impacto, autonomia, escala e dificuldade de reversão.
4. Outputs de IA são tratados como propostas até existir validação adequada ao risco.
5. As pessoas afetadas recebem informação e vias de contestação quando aplicável.
6. Cada sistema tem métricas, logs, supervisão, fallback e critério de suspensão.

## 3. Classes internas de utilização

### Verde — utilização assistiva de baixo impacto

Exemplos permitidos, sujeitos às regras de dados:

- brainstorming e estruturação;
- resumo de informação pública;
- revisão linguística sem dados sensíveis;
- apoio à pesquisa com validação de fontes.

Owner: utilizador e responsável da equipa.  
Evidência mínima: ferramenta autorizada e revisão do output.

### Âmbar — revisão obrigatória antes de utilização

Exemplos:

- conteúdo enviado a clientes;
- classificação ou extração que alimenta um processo;
- recomendações com impacto operacional;
- utilização de dados internos, pessoais ou confidenciais;
- integração com sistemas e ações automáticas reversíveis.

Owner: owner do processo.  
Aprovações: [segurança / privacidade / jurídico / risco, conforme o caso].  
Evidência mínima: teste, critérios de aceitação, supervisão, logs e fallback.

### Vermelho — proibido sem avaliação e aprovação formal

Exemplos internos a adaptar:

- decisões de emprego, crédito, saúde, acesso ou elegibilidade sem revisão adequada;
- introdução de segredos, credenciais ou dados não autorizados em ferramentas;
- impersonação, manipulação ou conteúdo enganador;
- vigilância, biometria ou inferência sensível sem base e análise específicas;
- ações irreversíveis ou de elevado impacto sem autoridade humana definida.

Owner da exceção: [função].  
Processo de aprovação: [ligação ou descrição].

## 4. Registo de sistemas

Cada utilização registada inclui:

- nome, finalidade e estado (teste, piloto, produção, suspenso, terminado);
- owner de negócio e owner técnico;
- fornecedor, modelo e versão quando disponíveis;
- dados de entrada, outputs e pessoas afetadas;
- integrações, permissões e ações possíveis;
- classe de impacto e fundamento;
- métricas, testes e limitações conhecidas;
- supervisão, fallback, incidentes e data de revisão.

Local do registo: [ligação].

## 5. Dados, segurança e fornecedores

- Ferramentas autorizadas: [lista ou ligação].
- Categorias que nunca podem ser introduzidas: [lista].
- Regras de retenção e eliminação: [regras].
- Avaliação mínima de fornecedor: dados, subcontratantes, localização, segurança, propriedade intelectual, portabilidade, disponibilidade e custos.
- Credenciais e segredos são geridos fora de prompts e documentos de trabalho.

## 6. Supervisão humana

Para cada utilização relevante, definir:

- quem revê;
- que contexto e evidência recebe;
- quanto tempo tem;
- quando deve rejeitar, corrigir ou escalar;
- que autoridade tem para suspender o sistema;
- como uma pessoa afetada pode contestar a decisão.

Uma confirmação automática ou uma caixa de validação sem contexto não conta como supervisão efetiva.

## 7. Qualidade, monitorização e alterações

- Baseline do processo: [métrica e período].
- Critérios de aceitação: [qualidade, latência, custo, segurança].
- Casos de falha testados: [lista].
- Alertas e owner operacional: [detalhe].
- Alterações de fornecedor, modelo, prompt, dados ou integração exigem [nível de nova revisão].
- Critérios de rollback/suspensão: [limiares].

## 8. Incidentes

Canal de reporte: [canal].  
Primeira resposta: [função e prazo interno].  

Registar:

- o que aconteceu e quando;
- sistema, versão e pessoas/processos afetados;
- dados envolvidos;
- contenção executada;
- decisão de manter, restringir, suspender ou terminar;
- comunicação e obrigações legais avaliadas por responsáveis competentes;
- ação corretiva e verificação posterior.

## 9. Literacia e responsabilidades

A formação é proporcional ao papel e ao risco. Deve cobrir capacidades, limitações, dados permitidos, validação de outputs, incidentes e vias de escalamento.

| Papel | Responsabilidade mínima |
| --- | --- |
| Utilizador | Usar apenas ferramentas autorizadas, validar outputs e reportar falhas |
| Owner do processo | Definir finalidade, baseline, risco, supervisão e decisão de continuidade |
| Tecnologia/segurança | Rever arquitetura, acessos, logs, alterações e resposta técnica |
| Privacidade/jurídico/risco | Rever obrigações e impacto quando aplicável |
| Direção | Aprovar exceções e aceitar risco residual dentro da sua autoridade |

## 10. Exceções, revisão e histórico

Exceções exigem owner, duração, fundamento, controlos compensatórios e aprovação registada.

Cadência de revisão: [trimestral/semestral/anual e após alteração material].

| Versão | Data | Alteração | Aprovador |
| --- | --- | --- | --- |
| 1.0 | [data] | Primeira versão adaptada | [função] |