Um guia completo da plataforma — o que faz, como funciona e por que está construída assim.
Versão 1.1 · setembro de 2026
Prefácio
A maioria das ferramentas de governação de IA são folhas de cálculo disfarçadas. Fazem umas quantas perguntas, desenham um gráfico radar e entregam-lhe um PDF que envelhece no momento em que a sua direção financeira o lê.
A E-ARI foi construída para fazer algo mais difícil: transformar a realidade desarrumada, regulada e em movimento da adoção de IA na empresa num único registo vivo, onde os sistemas, as obrigações, as provas e as ações revistas se acumulam ao longo do tempo. Um número num painel é fácil. Uma pista de auditoria defensável que sobreviva à apreciação de um organismo notificado daqui a três anos não é.
Este documento explica cada parte da plataforma — o registo que classifica os seus sistemas de IA e lhes associa as obrigações aplicáveis, as provas e as ações revistas que as sustentam, as exportações que um revisor pode verificar, a monitorização que procura novas lacunas, e a avaliação de preparação e os agentes de IA que diagnosticam as práticas da organização.
Leia-o de ponta a ponta ou salte para a secção de que precisa. Há um glossário no final se algum termo lhe parecer pouco familiar.
Índice
- O que é a E-ARI
- O problema que resolvemos
- Como a E-ARI está estruturada
- O espaço de governação
- Monitorização contínua
- A avaliação de preparação
- Os agentes de IA
- O percurso do utilizador
- Metodologia e pontuação
- Privacidade, segurança e tratamento de dados
- Planos e preços
- A quem se destina
- Roteiro
- Glossário
1. O que é a E-ARI
A E-ARI (o nome nasceu como Enterprise AI Readiness Index) é uma plataforma de governação de IA e de provas construída em torno do Regulamento da UE sobre a IA. Ajuda uma organização a responder a cinco perguntas, por esta ordem:
| Pergunta | Resposta da E-ARI |
|---|---|
| Que sistemas de IA usamos e como estão classificados? | Um registo com uma classificação do risco decidida por regras para cada sistema (artigos 5.º / 6.º / 7.º + anexo III). |
| Que obrigações se aplicam a cada sistema? | Uma lista de obrigações por sistema, delimitada pelo nível de risco e pelo papel do operador. |
| Temos as provas que o sustentam? | Um cofre de provas tipado com extração automática de cláusulas, que liga cada prova às obrigações que sustenta. |
| Quem corrige o quê, e foi revisto? | Ações de melhoria com um responsável, um prazo, provas associadas e um passo de revisão. |
| Um revisor pode verificar o registo? | Exportações seladas com manifestos assinados que um verificador independente pode confirmar. |
A par do registo, uma avaliação de preparação em 8 pilares, comparada com o seu setor, diagnostica as práticas da organização; o resumo semanal de conformidade, o registo de alterações regulamentares e os lembretes antes dos prazos de atestação mantêm o registo atual. O resultado não é um PDF único: sistemas, obrigações, provas, ações revistas, avaliações de impacto sobre os direitos fundamentais, documentações técnicas e pontuações de preparação mantêm-se versionados e exportáveis.
2. O problema que resolvemos
2.1 O panorama da conformidade mudou em 2024
O Regulamento da UE sobre a IA entrou em vigor a 1 de agosto de 2024 com aplicação faseada, alterado pelo Digital Omnibus sobre a IA (Regulamento (UE) 2026/1744, em vigor a 27 de julho de 2026):
- 2 de fevereiro de 2025 — aplicam-se os artigos 5.º (práticas proibidas) e 4.º (literacia no domínio da IA).
- 2 de agosto de 2025 — governação, obrigações relativas a modelos de IA de finalidade geral, coimas e designação de organismos notificados.
- 2 de agosto de 2026 — aplicam-se os deveres de transparência do artigo 50.º (as pessoas têm de saber que interagem com uma IA, e os conteúdos gerados por IA têm de ser marcados).
- 2 de dezembro de 2026 — mais duas proibições (imagens íntimas não consentidas; material de abuso sexual de crianças) e deveres de marcação para sistemas de conteúdo sintético já no mercado antes de 2 de agosto de 2026.
- 2 de dezembro de 2027 — aplicam-se as obrigações de risco elevado aos sistemas autónomos do anexo III. O Digital Omnibus adiou esta data face a 2 de agosto de 2026 — é tempo adicional de construção para uma avaliação de impacto e uma documentação técnica do anexo IV, não um motivo para esperar.
- 2 de agosto de 2028 — obrigações de risco elevado para a IA integrada em produtos regulados (anexo I).
As coimas chegam a 35 M€ ou 7 % do volume de negócios mundial por violação das práticas proibidas. Não existe uma versão «trataremos disso no próximo trimestre».
2.2 As ferramentas existentes falham de três formas previsíveis
| Modo de falha | Que aspeto tem | O que lhe custa |
|---|---|---|
| Modelos de maturidade em folha de cálculo | Quatro cores num separador, copiado entre equipas todos os trimestres. | Sem controlo de versões, sem defensabilidade, sem ligação a provas reais. |
| Projetos das grandes consultoras | Um relatório de 200 páginas, exato no dia em que é entregue. | Custo alto, cadência baixa — quando chega a avaliação seguinte, o panorama regulamentar já mudou. |
| Plataformas GRC genéricas | Módulos de conformidade com uma caixa genérica de «IA» aparafusada. | Sem tratamento nativo da avaliação de impacto sobre os direitos fundamentais (artigo 27.º) nem da documentação técnica do anexo IV. Sem classificador de risco. Sem ligação de provas ao nível da cláusula. |
2.3 O que a E-ARI otimiza
Três propriedades que tratamos como inegociáveis:
- Defensabilidade — cada recomendação, cada classificação e cada lacuna é rastreável até uma cláusula de um regulamento, uma frase de uma prova ou uma pergunta da avaliação. Sem veredictos opacos de um modelo de linguagem.
- Acumulação — o trabalho feito num sítio alimenta o seguinte. Cada sistema registado é classificado por regras, e as suas obrigações decorrem dessa classificação. Uma prova carregada para uma obrigação liga-se automaticamente a outras. Fechar uma lacuna num sistema atualiza a monitorização de toda a carteira.
- Disciplina de âmbito — deliberadamente não tentamos ser uma ferramenta de gestão de projetos, um gigante do GRC ou um registo de modelos. A E-ARI fica entre a sua equipa de estratégia e as suas autoridades de controlo.
3. Como a E-ARI está estruturada
A plataforma está construída como quatro camadas que cooperam em torno de um único registo. Cada camada tem o seu próprio modelo de dados e as suas próprias superfícies de interface, e todas trabalham sobre esse mesmo registo.
| Camada | Nome | Componentes |
|---|---|---|
| 04 | Monitorização contínua | Radar de lacunas · Registo de alterações regulamentares · Calendário de atestações · Resumos semanais |
| 03 | Registos e resultados | Gerador de avaliações de impacto · Gerador de documentação técnica · Pacote de submissão · Exportações seladas e verificáveis · Relatórios de governação |
| 02 | Provas e ações | Cofre de provas · Extração de cláusulas · Controlos · Ações com decisões revistas · Despesa em IA |
| 01 | Registo de sistemas de IA | Registo · Classificador de risco por regras · Obrigações aplicáveis |
A par das camadas, a avaliação de preparação (8 pilares, 40 perguntas), as verificações de pulso e os agentes de IA diagnosticam as práticas da organização. O registo não requer uma avaliação; um sistema pode, opcionalmente, ser ligado a uma avaliação concluída.
4. O espaço de governação
Este é o núcleo da E-ARI: o registo que uma autoridade de controlo, um cliente ou a sua própria auditoria interna irá pedir. O espaço de governação mapeia os seus sistemas de IA no Regulamento da UE sobre a IA e produz as peças que sustentam cada obrigação aplicável.
4.1 O registo de sistemas de IA
Cada sistema de IA que opere ou implante é registado com:
- Nome e finalidade — descrição em linguagem clara
- Papel na implantação — prestador, responsável pela implantação, importador, distribuidor (determina que obrigações se aplicam)
- Setor e populações afetadas — orienta a lógica de classificação do risco
- Ligação à sua base de preparação — herda automaticamente o seu contexto organizacional
- Perfil de inventário — o tipo de sistema (assistente, funcionalidade de IA, modelo, agente), a fase do ciclo de vida, a equipa que o opera, os dados que trata e a sua origem; num agente, até que ponto age sozinho e a que tem acesso (§4.16)
O plano Gratuito regista até 3 sistemas de IA e o Pro até 25; o Enterprise não tem limite.
4.2 O classificador de risco
Para cada sistema registado corre um classificador face à taxonomia de risco do Regulamento:
| Nível de risco | Desencadeador | O que geramos |
|---|---|---|
| Proibido (art. 5.º) | Práticas subliminares ou de exploração, classificação social, identificação biométrica à distância em tempo real em espaços públicos | Orientação de cessação, com os artigos citados |
| Risco elevado (art. 6.º + anexo III) | Componentes de segurança, biometria, educação, emprego, serviços essenciais, aplicação da lei, etc. | Documentação técnica completa do anexo IV + avaliação de impacto sobre os direitos fundamentais + plano de acompanhamento pós-comercialização |
| Risco limitado (art. 50.º / 52.º / 53.º) | Chatbots, ultrafalsificações, reconhecimento de emoções, categorização biométrica | Kit de obrigações de transparência (modelos de aviso, textos de divulgação) |
| Risco mínimo | Tudo o resto | Lista leve de obrigações (literacia, adesão voluntária a códigos) |
Cada classificação é entregue com uma fundamentação: os artigos concretos que desencadearam o nível, a orientação pública que os interpreta e a ambiguidade residual (para que o seu EPD possa sobrepor-se caso a posição da autoridade evolua).
4.3 O cofre de provas
Um armazém de objetos tipado para provas de conformidade:
- Contratos, avaliações de impacto sobre a proteção de dados, fichas de modelo, documentação de conjuntos de dados, registos de formação, auditorias de segurança, relatórios de equidade, etc.
- Provas ao nível da organização (válidas para todos os sistemas) e provas por sistema
- Versionadas — substituir uma prova cria uma nova versão, ficando a anterior ligada às avaliações de impacto históricas
- Armazenadas no Vercel Blob com acesso privado; URL pré-assinados para descarga (cerca de 5 minutos de validade)
Ao carregar um ficheiro acontecem duas coisas automaticamente:
- Classificação — um modelo de linguagem categoriza o tipo de documento (avaliação de impacto, ficha de modelo, relatório de auditoria, etc.)
- Extração de cláusulas — o documento é dividido e um modelo de linguagem identifica que cláusulas ou frases correspondem a que artigo do Regulamento. Essas correspondências são guardadas como registos
EvidenceClausee ficam reutilizáveis entre obrigações.
Uma avaliação de impacto que carregue para um sistema pode satisfazer automaticamente partes de três obrigações diferentes em dois sistemas.
4.4 O gerador de avaliações de impacto sobre os direitos fundamentais (artigo 27.º)
Para os sistemas de risco elevado, a avaliação de impacto sobre os direitos fundamentais é obrigatória.
O gerador da E-ARI:
- Recolhe os metadados do seu sistema de IA (finalidade, populações afetadas, papel na implantação)
- Recolhe as cláusulas de prova já ligadas a artigos sobre direitos fundamentais
- Gera uma avaliação estruturada que cobre: descrição do processo, períodos, frequência, categorias de pessoas singulares afetadas, riscos concretos de dano, disposições de governação, mecanismos de reclamação
- Mostra as lacunas no próprio texto (p. ex. «Não foram encontradas provas sobre a conceção da supervisão humana — requisito do artigo 14.º»)
- Exporta em PDF e
.docxcom citações de origem incorporadas
Só pode finalizar uma avaliação de impacto quando todas as secções exigidas tiverem provas de suporte. As incompletas ficam guardadas como rascunhos.
4.5 O gerador de documentação técnica (anexo IV)
A documentação técnica do anexo IV é o documento formal que um organismo notificado ou uma autoridade de fiscalização pedirá primeiro.
A E-ARI gera a estrutura completa exigida pelo anexo IV:
- Descrição geral do sistema de IA
- Descrição detalhada (métodos de desenvolvimento, ferramentas de terceiros, conjuntos de dados de treino)
- Informação sobre acompanhamento, funcionamento e controlo
- Documentação do sistema de gestão de riscos
- Registo de alterações do ciclo de vida
- Métricas de desempenho, limiares de exatidão, testes de robustez
- Lista das normas harmonizadas aplicadas
- Declaração de conformidade (modelo)
- Plano de acompanhamento pós-comercialização
Cada secção bebe do seu cofre de provas e do seu plano de acompanhamento. As secções sem provas de suporte ficam claramente assinaladas, para que saiba exatamente o que falta.
4.6 O radar de lacunas
Uma vista em direto do que falta:
- Por obrigação: cláusulas exigidas no total face às cláusulas atualmente provadas
- Ponderado pela gravidade (uma lacuna na gestão de riscos do artigo 9.º pesa muito mais do que uma no registo do artigo 53.º para um sistema que não é de finalidade geral)
- Envelhecimento — as lacunas abertas há mais de 30 dias sobem para o topo
- Cada lacuna tem um fluxo «Resolver» de um clique, que pede o tipo de prova concreto necessário
4.7 O pacote de submissão
Uma única exportação .zip, pronta a entregar a um organismo notificado, a um auditor ou ao seu próprio departamento jurídico:
- Documentação técnica do anexo IV (PDF)
- Avaliação de impacto sobre os direitos fundamentais (PDF, se de risco elevado)
- Todos os ficheiros de prova citados
- Relatório de cobertura de obrigações
- Plano de acompanhamento
- Manifesto com somas de verificação SHA-256 como prova de integridade
4.8 Descoberta de IA-sombra
A maioria das organizações descobre ferramentas de IA cuja utilização desconhecia: uma exportação de utilização de aplicações lista-as, mas nada lê essa lista face a um modelo de risco. O Discovery fecha essa falha sem qualquer trabalho de integração: exporte a sua lista de utilização de aplicações do Google Workspace, Okta ou Microsoft Entra (ou uma lista de comerciantes da sua ferramenta de despesas), carregue o CSV, e a E-ARI compara-a com um catálogo curado de ferramentas de IA — cada entrada anotada com o prestador, a categoria, se a ferramenta treina com dados de clientes por omissão, e a sua relevância para o Regulamento da UE sobre a IA.
As ferramentas correspondidas aparecem como não declaradas até as registar. Um clique promove uma ferramenta descoberta para o registo de sistemas de IA (§4.1), com o prestador criado automaticamente no módulo de risco de fornecedores — a partir daí aplica-se o pipeline habitual: classificação de risco, obrigações, provas.
4.9 Risco de prestadores de IA terceiros
Todo o produto de IA de terceiros é o modelo de outrem e as condições de dados de outrem. O módulo de risco de fornecedores envia a cada fornecedor um questionário versionado de cerca de 10 minutos (tratamento de dados, segurança, específicos de IA, jurídicos) através de uma ligação assinada — não precisam de conta do lado deles. A pontuação é determinista: cada resposta vale pontos, as perguntas por responder contam como o pior caso, e os sinais críticos (sem contrato de subcontratação, treino com dados de clientes, sem via de eliminação) forçam uma classificação crítica independentemente do valor numérico. Os documentos do fornecedor (contratos de subcontratação, relatórios SOC 2, listas de subcontratantes ulteriores) são carregados para o cofre de provas e passam pela mesma extração de cláusulas que as provas de sistema.
4.10 Conformidade com o artigo 4.º sobre literacia no domínio da IA
O artigo 4.º do Regulamento — em vigor desde 2 de fevereiro de 2025 — exige que o pessoal tenha literacia no domínio da IA suficiente para a sua função. A E-ARI inclui um currículo versionado (fundamentos da IA, o essencial do Regulamento, proteção de dados, uso responsável), atribuído aos membros da equipa através de ligações mágicas pessoais que expiram ao fim de 30 dias. As conclusões registam a pontuação do questionário e um hash de atestação SHA-256 que liga membro, módulo, marca temporal e versão do conteúdo. Toda a lista é exportável como relatório de prova pronto para uma autoridade; os membros em atraso são lembrados automaticamente todas as semanas.
4.11 Controlos contínuos
A vista de controlos responde à pergunta que um auditor realmente faz: que obligações está a cumprir neste momento? Cada obrigação aplicável aos seus sistemas registados recebe um estado em direto — cumprida (sustentada por pelo menos uma cláusula de prova extraída), não cumprida (uma lacuna crítica ou elevada em aberto) ou pendente (aplicável mas ainda sem provas) — além de avisos para as atestações que vencem em 30 dias. Os estados são derivados do cofre de provas e do radar de lacunas, nunca autodeclarados. Um resumo semanal só lhe é enviado quando há algo a fazer.
4.12 API pública
A API faz parte do plano Enterprise, com leitura e escrita. Os pontos de acesso em /api/v1/ expõem avaliações, o registo de IA, resultados de risco de fornecedores e estados de controlo derivados, autenticados com chaves revogáveis de âmbito limitado. A referência está em /developers.
4.13 Ações e decisões revistas
O trabalho de governação precisa de um responsável e de um registo do que foi decidido. Uma ação pode nascer de uma pergunta da avaliação, de uma obrigação ou controlo num sistema, de um registo de prova, de um contrato ou de um incidente. Cada origem tem uma chave estável, por isso pedi-la duas vezes abre a mesma ação, nunca um duplicado. Uma ação tem uma pessoa atribuída, um prazo, as provas que a sustentam e um resultado; quando o trabalho é submetido, um proprietário ou administrador revê-o.
Concluir uma revisão cria um registo a que só se acrescenta e que nunca é reescrito: a decisão e a justificação da pessoa, separadas da recomendação do sistema, com o revisor, a versão das regras, um instantâneo da origem, as referências das provas e as respetivas impressões digitais, e a data da próxima revisão. As decisões sobre contratos e os riscos aceites têm de fixar essa data. Uma revisão sustentada por provas pode fechar uma constatação de obrigação registada; aceitar um risco não a fecha, e nenhuma das duas altera a cobertura determinística nem a classificação jurídica.
Uma decisão vale o que valem os factos em que assentou. Quando mudam (o custo, o responsável ou as ligações de um contrato, o estado do fornecedor, o contexto de governação do sistema, as provas ou a sua atualidade, o escalão de utilização, a recomendação em vigor), a decisão passa de imediato a exigir revisão, e a tarefa diária de monitorização da conformidade reabre a mesma ação. Um registo renomeado ou uma observação mais recente não invalida, por si só, uma decisão. A vista geral e o resumo semanal começam pelas constatações críticas, pelo trabalho em atraso e pelas decisões que voltam a exigir revisão.
4.14 Despesa em IA e decisões de adoção
A Despesa em IA (Pro e Enterprise) é um registo dos contratos de IA que paga: a ferramenta, a categoria, o preço por lugar ou por utilização, o custo anual, a moeda, a data de renovação, o pré-aviso, o responsável, o fornecedor e os sistemas que suporta. Para cada contrato responde a uma só pergunta: mantê-lo, cortá-lo, corrigi-lo primeiro ou escolher entre dois que fazem o mesmo trabalho. A resposta de governação vem primeiro: uma utilização proibida, um sistema não classificado ou um acordo de tratamento de dados em falta aparece acima do número de lugares.
Os números mantêm-se rastreáveis. O custo por pessoa ativa é o custo anual dividido pelas pessoas contadas no próprio export de utilização do fornecedor; nada é convertido entre moedas e nada é projetado. As importações de utilização guardam contagens por período, nunca por pessoa: as pessoas são desduplicadas por um identificador estável ou por e-mail, e os identificadores são depois descartados. As linhas agregadas exigem a confirmação explícita de que os grupos são pessoas diferentes, importar o mesmo ficheiro duas vezes não altera nada, e substituir um relatório sobreposto exige confirmação e mantém o antigo como histórico substituído. Uma utilização desatualizada ou impossível não produz custo por utilizador nem números de lugares por usar.
As regras recomendam; uma pessoa decide. A decisão fica registada como decisão revista (§4.13), com uma nota e uma data para a próxima revisão. Os lembretes caem na data de renovação menos o pré-aviso registado. Quando o pré-aviso é desconhecido, usa-se a data de renovação, assinalada como não confirmada.
4.15 Relatórios de governação
Os relatórios (/portal/reports) captam todo o espaço de trabalho tal como está, independentemente de qualquer avaliação. Um único relatório de governação serve a direção, e referências de origem numeradas, cada uma com ligação ao registo de onde veio, apoiam o acompanhamento de auditoria. Abrange os assuntos que exigem atenção, o inventário de sistemas e os seus responsáveis, o programa de governação (os órgãos de governação e a verificação antes da entrada em produção, a política de IA e as suas confirmações, o registo de riscos, as avaliações de impacto e, uma vez registada, a declaração de aplicabilidade ISO/IEC 42001), a cobertura candidata das obrigações, a garantia sobre provas e revisões, as ações e decisões, as observações registadas no período escolhido, a exposição a fornecedores e contratos e o contexto das avaliações guardadas. Não contém narrativa escrita por um modelo nem qualquer pontuação composta de governação.
Um relatório é um instantâneo do estado atual, não uma reconstrução do passado: a data do período de atividade apenas filtra as observações de monitorização registadas. O conteúdo captado é guardado com a respetiva impressão digital SHA-256, que o identifica mas não é uma assinatura independente; as exportações seladas dos sistemas continuam a ser o resultado de garantia especializado. Cada relatório é comparado com o relatório anterior da mesma edição. A edição partilhada deixa de fora os custos dos contratos e a fundamentação privada dos contratos; a edição restrita inclui-os, e só proprietários e administradores a podem abrir.
Qualquer pessoa que possa editar o espaço de trabalho pode criar um relatório. Criar um relatório consome a quota mensal de relatórios (§11.1); descarregar um relatório guardado não a consome. Um relatório começa como rascunho. Um proprietário ou administrador finaliza-o depois de o ler, com uma nota obrigatória; o PDF do rascunho original é guardado, e alterações posteriores exigem uma nova versão. Finalizar não é uma certificação regulamentar nem uma aprovação das decisões contidas no relatório. Por agora, o conteúdo dos relatórios está em inglês; os controlos à sua volta seguem o seu idioma.
4.16 O perfil de inventário
Um registo que nomeia um sistema mas não diz o que é, em que fase está ou em que toca não responde às perguntas para as quais se mantém um inventário. Cada sistema pode registar o seu tipo (um assistente ou chatbot, uma funcionalidade de IA num produto, um modelo que a organização treina ou aloja, ou um agente que executa ações), a sua fase do ciclo de vida (planeado, piloto, em produção, retirado), a equipa ou unidade que o opera, as categorias de dados que trata (categorias especiais, dados biométricos, dados de crianças, dados pessoais, dados de trabalhadores, dados confidenciais ou apenas informação pública) e de onde vêm esses dados. Para um agente, regista ainda até que ponto age sozinho, o que pode fazer e a que tem acesso.
Nenhum destes campos altera a classificação ao abrigo do Regulamento da IA, que lê a finalidade, a descrição, o setor e as pessoas afetadas, pelo que editá-los nunca torna uma determinação provisória. Alimentam a verificação de entrada em produção, as regras de dados da política e a declaração ISO/IEC 42001, e o registo pode ser filtrado por agentes, dados pessoais e sistemas em produção. O perfil faz parte do registo em todos os planos.
4.17 A estrutura de governação e a verificação de entrada em produção
A governação (Pro e Enterprise) regista quem decide. Os órgãos de governação — uma comissão, um conselho, um grupo designado — têm um mandato, uma periodicidade de reunião, membros e as decisões que lhes cabem (entradas em produção, aceitação de riscos, a política de IA, pedidos de ferramentas). Os membros não precisam de conta: um proprietário ou administrador regista a decisão do órgão em seu nome, e o registo indica quem a registou. Cada sistema designa um responsável, a pessoa que assegura a supervisão humana durante a utilização (art. 14.º; art. 26.º, n.º 2, para os responsáveis pela implantação) e quem aprova a sua entrada em produção.
A verificação de entrada em produção define o que tem de ser verdade antes de um sistema passar a produção. Cada requisito lê um registo que o produto já mantém: um responsável designado, supervisão humana atribuída, uma classificação não provisória, nenhuma lacuna crítica aberta, uma avaliação de impacto sobre os direitos fundamentais (FRIA) e documentação técnica finalizadas quando o motor de obrigações as aplica, uma avaliação de impacto concluída, um registo de riscos sem riscos elevados ou críticos sem tratamento, uma política de IA publicada e uma aprovação. A organização escolhe os requisitos obrigatórios e pode acrescentar os seus próprios, que uma pessoa confirma para cada sistema. A verificação é indicativa por defeito; imposta, o registo recusa a passagem a produção até os requisitos obrigatórios estarem cumpridos e indica quais faltam.
A aprovação é uma decisão revista (§4.13). Regista a lista tal como estava e fica desatualizada logo que algo nela muda, como qualquer outra decisão revista.
4.18 A política de IA
A política de IA (Pro e Enterprise) reúne as regras com que os trabalhadores trabalham: que ferramentas estão aprovadas e para quê, a informação mais sensível que cada uma pode ver, o que pode ser introduzido numa ferramenta de IA consoante a classe de informação, o que nunca é permitido (incluindo as práticas proibidas pelo art. 5.º), como os resultados da IA são verificados e assinalados, a formação em literacia no domínio da IA exigida, quem aprova novas ferramentas e como comunicar uma preocupação. A organização faz cada escolha num rascunho; o E-ARI redige o documento a partir dessas escolhas em inglês, francês, português, espanhol ou alemão. O modelo escreve frases; não decide nenhuma regra.
Publicar fixa o rascunho guardado como a versão seguinte: o texto gerado e um SHA-256 calculado sobre ele, com uma nota de publicação e uma data de revisão. Uma versão publicada nunca muda; uma alteração é uma nova versão. As pessoas da equipa recebem uma ligação pessoal, válida durante 30 dias e sem necessidade de conta, para ler a versão e confirmar a leitura. Cada confirmação indica a versão lida e inclui um resumo com chave; se for publicada uma versão mais recente durante a leitura, a confirmação é recusada e a pessoa lê a nova. Qualquer pessoa com lugar de membro pode pedir uma ferramenta que a política não aprova; o pedido é decidido como uma decisão revista, e aprová-lo adiciona a ferramenta ao rascunho, não ao texto publicado.
4.19 O registo de riscos e as avaliações de impacto
O registo de riscos (Pro e Enterprise) regista o que pode correr mal com cada sistema. Uma pessoa avalia a probabilidade e o impacto de 1 a 5; o nível é o produto dos dois, dividido por limiares fixos indicados junto a cada pontuação (1–4 baixo, 5–9 médio, 10–15 elevado, 16–25 crítico). Cada risco tem uma categoria, um tratamento (mitigar, aceitar, transferir ou evitar), um plano de tratamento, uma avaliação opcional depois do tratamento, um responsável e uma data de revisão. Aceitar um risco, ou confirmar que o tratamento resultou, é uma decisão revista, e um risco decidido que é reavaliado ou recebe outro tratamento volta a abrir. O registo mostra todos os riscos, primeiro a pontuação atual mais alta, com um mapa de 5 × 5 antes e depois do tratamento.
A avaliação de impacto cobre todos os sistemas, como pede a ISO/IEC 42001 A.5: quem o sistema afeta, como pode afetar pessoas e grupos, os seus efeitos mais amplos na sociedade, a gravidade, a extensão e a reversibilidade desses efeitos, como pode ser supervisionado ou contestado, e o que está implementado. As respostas são escritas por uma pessoa; o produto não as pontua nem tira conclusões. Concluí-la regista quem a concluiu e a data da próxima revisão, e alterar uma resposta volta a torná-la rascunho. Para um sistema de IA de risco elevado sujeito à avaliação de impacto sobre os direitos fundamentais do art. 27.º, a FRIA (§4.4) continua a ser o registo legal.
4.20 A declaração de aplicabilidade ISO/IEC 42001
A declaração de aplicabilidade (Enterprise) enumera os 38 controlos do anexo A da ISO/IEC 42001, agrupados por objetivo. Para cada um, a organização regista se se aplica — com a justificação que a cláusula 6.1.3 pede quando não se aplica —, o grau de implementação e a forma como é cumprido. O E-ARI nunca define esse estado. Ao lado de cada controlo, enumera os registos do espaço de trabalho relacionados (a política publicada e a sua data de revisão, os órgãos de governação, os responsáveis e a supervisão, as avaliações de impacto, os trabalhadores formados, as aprovações de entrada em produção, os riscos, os incidentes, as avaliações e acordos com fornecedores) como contagens com ligação à origem, e a evidência arquivada nos tipos de artefacto correspondentes. Um controlo sem nada por trás não está evidenciado no E-ARI, o que não é o mesmo que não implementado. A declaração exporta-se em CSV. A certificação é decidida por um organismo de certificação acreditado; a correspondência entre registos e controlos é do E-ARI.
5. Monitorização contínua
A conformidade não é um projeto. É um processo que corre indefinidamente.
5.1 Verificações de pulso
Pontos de situação mensais leves, dirigidos às perguntas mais sensíveis ao desvio (governação, segurança, talento). Demoram 3 a 5 minutos. Geram um relatório de diferenças face à sua última avaliação completa.
5.2 Registo de alterações regulamentares e monitorização da conformidade
A E-ARI não recolhe um fluxo regulamentar. As datas regulamentares vêm de uma única fonte curada e versionada — o registo de alterações regulamentares, que publica o texto consolidado do Regulamento com que trabalha — e cada motor lê as suas datas dessa fonte.
Uma tarefa agendada diária (/api/cron/compliance-monitoring) verifica os seus planos de acompanhamento e envia um lembrete de atestação devida quando a próxima atestação de um sistema cai nos 30 dias seguintes — no máximo um email de lembrete por sistema e por semana, mais uma notificação na aplicação. O resumo semanal (§5.4) cobre controlos não cumpridos, provas pendentes e atestações devidas.
5.3 Calendário de atestações
O anexo IV exige atestações periódicas para os sistemas de risco elevado. A plataforma acompanha:
- As datas de reavaliação anual da conformidade
- As janelas de atualização das avaliações de impacto sobre a proteção de dados (a cada 24 meses para sistemas em evolução)
- Os prazos dos relatórios de acompanhamento pós-comercialização
- Os ciclos de revisão interna (configuráveis por sistema)
Quando um prazo cai nos 30 dias seguintes, a tarefa diária de conformidade envia um lembrete de atestação devida — no máximo um por sistema e por semana — e cria uma notificação na aplicação. É este o comportamento de lembrete entregue; não existe uma cadência escalonada de 60/30/7/1 dias.
5.4 Notificações por email e na aplicação
Todas as notificações são entregues pelo sistema unificado de modelos:
- Resumo semanal de conformidade (planos pagos — enviado apenas quando há algo a fazer)
- Deteção de desvio agendada com alertas na mudança — as verificações de pulso e o motor de monitorização sinalizam regressões da pontuação; os alertas disparam na mudança, não continuamente
Cancelamento de subscrição e gestão de preferências em /portal/preferences.
6. A avaliação de preparação
A avaliação de preparação é um diagnóstico de apoio das práticas da organização. O registo de sistemas não a requer, e nem a sua pontuação nem o seu nível de preparação constituem uma determinação de conformidade.
6.1 Os 8 pilares
Pontuamos a preparação em oito pilares, com ponderações derivadas da literatura de investigação sobre fatores de sucesso na adoção de IA. As ponderações somam 1,00.
| # | Pilar | Ponderação | O que mede |
|---|---|---|---|
| 1 | Estratégia e visão | 15 % | Estratégia de IA formal, patrocínio da direção, medição do retorno, roteiro plurianual. |
| 2 | Dados e infraestrutura | 15 % | Qualidade dos dados, acessibilidade, governação, maturidade ETL/MLOps, capacidade de cálculo. |
| 3 | Tecnologia e ferramentas | 12 % | Plataformas de ML, ferramentas do ciclo de vida dos modelos, diversidade de fornecedores, arquitetura na nuvem. |
| 4 | Talento e competências | 13 % | Canal de recrutamento, formação interna, definição de funções, planos de sucessão. |
| 5 | Governação e ética | 15 % | Comités de ética, completude das políticas, auditoria de enviesamentos, responsabilização. |
| 6 | Cultura e mudança | 10 % | Psicologia da adoção, gestão da mudança, comunicação, tratamento de resistências. |
| 7 | Processos e operações | 10 % | Integração nos fluxos de trabalho, reengenharia de processos, ciclos de retorno, gestão de SLA. |
| 8 | Segurança e conformidade | 10 % | Segurança dos modelos, controlos de privacidade, alinhamento regulamentar, prontidão para auditoria. |
Cada pilar contém exatamente 5 perguntas numa escala de Likert (1–5). 40 perguntas no total. Tempo mediano de realização: cerca de 15 minutos.
6.2 Faixas de maturidade
Depois de ponderada, a pontuação global (0–100) corresponde a uma de quatro faixas:
| Faixa | Intervalo | Interpretação |
|---|---|---|
| Retardatário | 0–25 | Elementos de base mínimos. As iniciativas de IA são pontuais ou inexistentes. |
| Seguidor | 26–50 | Preparação em fase inicial. Algumas iniciativas, mas sem coesão nem alinhamento. |
| Perseguidor | 51–75 | Preparação em progresso. Alicerces assentes, investimento em curso. |
| Referência | 76–100 | Preparação avançada. Bem posicionado para uma vantagem competitiva assente na IA. |
As faixas são deliberadamente mais largas do que um percentil — servem para orientar comportamentos (onde investir), não para alimentar vaidades.
6.3 O que recebe de volta
Uma avaliação concluída produz um registo Assessment estruturado:
- Pontuação global (0–100, ponderada pelo setor) e pontuação de base (sem ponderação) por transparência
- Pontuações por pilar com desagregação ao nível da pergunta e os ajustamentos de interdependência aplicados
- Faixa de maturidade com uma interpretação em linguagem clara
- Constatações X-Ray — padrões estruturais de risco detetados a partir de combinações de respostas (ver §9.4), cada uma com gravidade, rasto de provas, impacto no negócio e uma ação concreta
- Aplicação da ponderação setorial — que pilares foram acentuados para o seu setor e porquê
- Comparação setorial (as suas pontuações face a médias setoriais curadas)
- Matriz de forças e fraquezas — os três melhores pilares e os três últimos
- Mapeamento regulamentar inicial — os pilares que se alinham com a regulamentação aplicável (RGPD, Regulamento da UE sobre a IA, ISO 42001, NIST AI RMF)
- Análise de alavanca — o pipeline é reexecutado melhorando cada resposta um degrau, ordenando cada movimento possível pelo seu ganho exato na pontuação global (incluindo a libertação de regras de interdependência e a ponderação setorial), mais um caminho ganancioso simulado até à faixa de maturidade seguinte
Este registo é a semente de tudo o resto. O essencial: as constatações X-Ray são aquilo em que cada agente a jusante ancora a sua narrativa — o relatório que recebe fica assim preso aos seus padrões estruturais concretos, e não a uma redação genérica dos seus números.
7. Os agentes de IA
Quando uma avaliação termina, um orquestrador executa um pipeline de seis agentes. Cada agente tem uma única tarefa, e as saídas dos agentes anteriores alimentam as entradas dos seguintes.
O pipeline corre em quatro etapas sequenciais:
| Etapa | Agentes | Modo | Papel |
|---|---|---|---|
| 1 | Pontuação | Sequencial · corre primeiro | Aritmética determinista — produz a base numérica |
| 2 | Insight + Discovery | Paralelo | Correm em simultâneo, já que as suas entradas não se sobrepõem |
| 3 | Relatório | Sequencial · compila | Junta as saídas das etapas 1 e 2 no documento de direção |
| 4 | Literacy | Sequencial · adaptativo | Currículo personalizado com base nos pilares mais fracos |
| — | Assistência | A pedido | Diálogo interativo, disponível depois do pipeline |
7.1 Agente de pontuação
Determinista, sem envolvimento de um modelo de linguagem, corre primeiro. Executa um pipeline de oito passos:
- Validar — cada pergunta exigida está respondida, contando como resposta uma anotação «Não sei» ou «Não aplicável»; um pilar com menos de três das suas cinco perguntas classificadas é recusado (
E_INSUFFICIENT_PILLAR_COVERAGE), e um sem qualquer classificação é recusado comoE_NO_PILLAR_COVERAGE - Normalizar — cada pilar é mapeado da sua soma de Likert para 0–100, sobre as perguntas efetivamente classificadas: os limites acompanham o número de respostas, pelo que uma pergunta anotada não puxa o pilar para baixo nem o inflaciona
- Ajustar — disparam seis regras documentadas de interdependência entre pilares (§9.2)
- Composto de base — o global sem ponderação é preservado por transparência
- Ponderação setorial — as ponderações dos pilares são reequilibradas para o setor da organização e renormalizadas para 1,0 (§9.3)
- Compor e classificar — pontuação global final, faixa de maturidade, sinalização de falhas críticas
- Deteção X-Ray — oito detetores estruturais percorrem as combinações de respostas (§9.4). Um detetor cujas entradas declaradas incluam uma pergunta anotada não corre e é reportado como «não pôde ser avaliado», nunca como um que correu e nada encontrou
- Simulação de alavanca — todo o pipeline é reexecutado subindo cada resposta um degrau, produzindo uma ordenação exata do ganho de pontuação de cada melhoria possível e um caminho ganancioso simulado até à faixa seguinte. Como o motor é determinista, estes são factos reproduzíveis e não estimativas — a mesma propriedade que permite a um cliente auditar a sua pontuação permite-lhe auditar o seu roteiro
A aritmética de pontuação é aberta e reproduzível. É o único passo determinista do pipeline — todos os outros agentes ancoram as suas saídas neste resultado de pontuação e nas suas constatações X-Ray, o que significa que as alucinações de um modelo de linguagem não podem mover a sua pontuação, e a narrativa não pode afastar-se dos seus padrões estruturais reais.
7.2 Agente Insight
Assente num modelo de linguagem, gera análises narrativas ancoradas no resultado de pontuação. Para cada pilar:
- Uma interpretação da pontuação em linguagem de negócio, em duas ou três frases
- Dois riscos concretos se a pontuação ficar onde está
- Duas oportunidades concretas que se abrem ao alcançar a faixa de maturidade seguinte
As saídas passam por um verificador de ancoragem — as afirmações que não se ligam a uma pontuação numérica do resultado são removidas antes de serem mostradas.
7.3 Agente Discovery
Corre em paralelo com o Insight, já que as suas entradas não se sobrepõem. O Discovery responde à pergunta «que aspeto tem realmente a sua organização vista de fora?»:
- Classifica automaticamente o seu setor com uma chamada de 30 tokens a um modelo de linguagem (sem contaminação entre setores)
- Recolhe sinais públicos através do Tavily Search e Extract (notícias recentes, comunicações a reguladores, padrões públicos de recrutamento)
- Sintetiza uma nota contextual: tendências do setor, anúncios de pares, pressão regulamentar observada
- As citações vão em linha,
[S1],[S2]— sem fonte, não há afirmação
Se o sinal público for fraco ou pouco fiável, o Discovery abdica de sintetizar em vez de fabricar uma leitura «de confiança média».
7.4 Agente de relatório
Compila tudo o que precede num documento de direção estruturado:
- Sumário executivo (uma página, ponderado pelo seu contexto setorial)
- Aprofundamento pilar a pilar, com análises e riscos
- As três ações recomendadas, cada uma ligada a pilares e obrigações concretos
- Secção de comparação com o contexto setorial vindo do Discovery
- Anexo: respostas completas, notas de metodologia, mapeamento regulamentar
Disponível como vista na aplicação, descarga .docx e PDF otimizado para impressão.
7.5 Agente Literacy
Adaptativo, corre depois do relatório. Olha para os seus pilares mais fracos e monta um minicurrículo personalizado:
- Artigos direcionados do hub Literacy
- Questionários calibrados à sua faixa de maturidade
- Percursos de aprendizagem recomendados (p. ex. «De Seguidor a Perseguidor em governação» — 4 módulos, cerca de 3 horas)
Ao contrário de uma base de conhecimento estática, o Literacy nunca recomenda conteúdos de pilares em que já é forte. Ganha o seu lugar no pipeline por ser personalizado.
7.6 Agente de assistência
A pedido, depois do pipeline. Uma interface de diálogo ancorada, com acesso só de leitura à sua avaliação, aos seus sistemas de IA, às suas provas e à sua cobertura de obrigações.
- Pergunta-se-lhe: «O que nos impede de ser Perseguidor?»
- Recusa responder a perguntas fora do seu âmbito de dados (sem aconselhamento geral sobre IA — apenas o que está ancorado no estado da sua plataforma)
- Todas as citações remetem para registos concretos da sua conta
8. O percurso do utilizador
A visão geral do seu portal segue estes quatro passos e mostra primeiro a próxima ação.
Passo 1 — Registar
Comece por um sistema de IA que usa de facto; a análise de IA fantasma encontra ferramentas que ninguém declarou. O classificador por regras fixa o nível de risco de cada sistema e as obrigações que se aplicam. O registo não requer uma avaliação de preparação.
Passo 2 — Governar
Reveja as classificações, ligue provas às obrigações que sustentam e resolva as ações de melhoria associadas aos seus sistemas. Os controlos mostram cada obrigação como sustentada, em falha ou a aguardar provas.
Passo 3 — Avaliar
Responda às 40 perguntas da avaliação de preparação para obter uma pontuação e uma faixa de maturidade em 8 pilares — um diagnóstico das práticas da organização cujas prioridades se tornam ações de melhoria.
Passo 4 — Manter
Reveja regularmente sistemas, provas e preparação. Acompanhe o registo de alterações regulamentares e o calendário de atestações, exporte registos selados que um revisor possa verificar e faça verificações de pulso entre avaliações.
9. Metodologia e pontuação
9.1 Normalização dos pilares
Para cada pilar p com perguntas q₁ … q₅ respondidas numa escala de Likert de 1 a 5:
pillar_score(p) = (Σ qᵢ - 5) / 20 × 100
Isto normaliza a soma bruta de 5–25 para uma escala de 0–100.
9.2 Regras de interdependência
Seis regras documentadas disparam sobre as pontuações normalizadas dos pilares. Cada regra tem uma fundamentação publicada e fica registada no registo de avaliação, para que qualquer ajustamento seja reproduzível.
| Regra | Desencadeador | Efeito | Porquê |
|---|---|---|---|
| R1 | Governação < 30 | Tecnologia × 0,70 | Ferramentas maduras sem governação são risco não controlado, não capacidade. |
| R2 | Dados < 30 | Estratégia × 0,85 | Estratégia sem base de dados é aspiração, não operação. |
| R3 | Segurança < 30 | Tecnologia × 0,85 | Modelos implantáveis sem controlos são uma responsabilidade. |
| R4 | Talento < 25 | Estratégia × 0,90 | A ambição que excede a capacidade interna não chega a ser entregue. |
| R5 | Governação < 35 e Segurança < 35 | Processos × 0,85 | A IA industrializada sem controlos multiplica incidentes à escala. |
| R6 | Cultura < 30 | Processos × 0,92 | Culturas resistentes à mudança não conseguem operacionalizar os ganhos da IA. |
As regras aplicam-se pela ordem declarada. A pontuação original, a ajustada e a regra que disparou ficam todas guardadas na avaliação para repetição em auditoria.
Composição: as regras aplicam-se por ordem ao valor corrente, pelo que cada regra atua sobre o que a anterior deixou. Exemplo resolvido: Governação 25, Segurança 25, Tecnologia 75: R1 dá 52,50; depois R3 aplica-se a 52,50 e dá 44,63. Se R3 tivesse atuado sobre o 75 original em vez do valor corrente, teria produzido 63,75 — o registo de auditoria guarda a entrada e a saída de cada regra, que é exatamente o que torna a cadeia repetível.
9.3 Ponderação setorial
As ponderações por omissão vivem no motor (15 % Estratégia, 15 % Dados, 12 % Tecnologia, 13 % Talento, 15 % Governação, 10 % Cultura, 10 % Processos, 10 % Segurança). Depois dos ajustamentos de interdependência, aplicam-se multiplicadores setoriais a essas ponderações e o resultado é renormalizado para somar 1,00. Assim a pontuação global mantém-se na escala de 0 a 100 e reflete ao mesmo tempo o que realmente importa em cada setor.
| Setor | Pilares acentuados (×) | Pilares atenuados (×) |
|---|---|---|
| Saúde | Governação ×1,35 · Segurança ×1,25 · Dados ×1,20 | Tecnologia ×0,90 · Cultura ×0,90 |
| Finanças | Governação ×1,30 · Segurança ×1,25 · Dados ×1,20 | Cultura ×0,85 · Talento ×0,90 |
| Indústria | Processos ×1,30 · Dados ×1,20 · Tecnologia ×1,15 | Cultura ×0,85 · Talento ×0,90 |
| Retalho | Dados ×1,30 · Processos ×1,20 · Tecnologia ×1,10 | Governação ×0,90 · Talento ×0,95 |
| Tecnologia | Tecnologia ×1,25 · Talento ×1,20 · Estratégia ×1,10 | Governação ×0,90 · Segurança ×0,95 |
| Setor público | Governação ×1,35 · Segurança ×1,25 · Dados ×1,10 | Talento ×0,90 · Cultura ×0,90 |
| Energia | Segurança ×1,30 · Dados ×1,20 · Processos ×1,15 | Talento ×0,90 · Cultura ×0,90 |
| Educação | Governação ×1,25 · Cultura ×1,20 · Segurança ×1,10 | Processos ×0,95 · Tecnologia ×0,95 |
A pontuação global de base sem ponderação é preservada ao lado da global ponderada pelo setor, para que os relatórios possam mostrar como o contexto setorial moveu o número — e porquê.
9.4 O motor X-Ray — deteção de padrões estruturais
Uma pontuação é um número. Um padrão é uma história. Duas organizações podem ambas ficar nos 47 % — uma porque é uniformemente medíocre, outra porque tem uma ambição agressiva em IA sem base de dados. As intervenções para essas duas não têm nada a ver.
O motor X-Ray executa oito detetores deterministas sobre o mapa de respostas e traz à superfície modos de falha estruturais que emergem do modo como as perguntas interagem entre pilares. Cada constatação traz a sua gravidade (baixa / média / elevada / crítica), as provas ao nível da pergunta que a desencadearam, o impacto no negócio em termos claros e uma única ação concreta recomendada.
| ID | Padrão | Desencadeador | Porque importa |
|---|---|---|---|
| P-01 | Risco de TI-sombra | Elevada adoção tecnológica + patamar de governação baixo | O caminho mais rápido para uma constatação de incumprimento do Regulamento. |
| P-02 | A lacuna de ambição | Elevada ambição estratégica + base de dados e governação partida | As iniciativas emblemáticas encravam em piloto entre os meses 9 e 12. |
| P-03 | O purgatório dos pilotos | Muito apetite de experimentação + baixa maturidade MLOps | Os pilotos param na demonstração quando há ferramentas sem o processo para as operacionalizar — e o apetite pela tentativa seguinte cai a cada uma que encrava. |
| P-04 | O precipício de conformidade | (governance_5 + governance_3 + security_5 ≤ 6) E (technology_3 ≥ 4 ∨ process_4 ≥ 4 ∨ technology_3 + process_4 ≥ 2) | O dever de literacia do artigo 4.º vincula hoje, seja o que for que implante; as obrigações de risco elevado dos sistemas autónomos do anexo III aplicam-se a partir de 2 de dezembro de 2027, e levantar uma avaliação de impacto mais uma documentação técnica leva trimestres. Crítico quando há capacidade real a ser implantada dentro dessa lacuna. |
| P-05 | Desajuste talento-estratégia | Elevada ambição em IA + pouca oferta interna de talento | Os roteiros derrapam e a despesa externa cresce para tapar o buraco; cada data falhada compra mais um prestador externo em vez da capacidade interna que a teria evitado. |
| P-06 | O ponto cego do enviesamento | Elevada maturidade de implantação + baixa equidade e transparência | Um incidente de enviesamento com esta forma é descoberto de fora e não de dentro, porque nada o vigia — o mesmo problema comunicado por um cliente ou por uma autoridade lê-se como falha de supervisão do artigo 14.º. |
| P-07 | Desligamento da direção | Forte capacidade operacional + fraco patrocínio da direção | Capacidade sem patrocínio fragmenta-se; os engenheiros de IA saem em menos de 18 meses. |
| P-08 | Desajuste de processos primeiro | Elevada maturidade de processos + camada de dados fraca | Equipas disciplinadas industrializam os resultados errados à escala. |
O bloco X-Ray é depois colocado à cabeça da instrução de cada agente a jusante. O agente Insight tem de ligar cada risco e cada passo seguinte que produz a um identificador de constatação. O agente de roteiro tem de neutralizar cada constatação CRÍTICA na fase 1 e cada constatação ELEVADA na fase 2. O agente Discovery tem de refletir as constatações nos seus indicadores de lacunas. É isto que faz o relatório parecer feito à medida — os agentes estão ancorados no seu conjunto de padrões concreto, não a parafrasear um número.
9.5 Intervalo de confiança
Um resultado de pontuação inclui uma banda de confiança derivada de:
- Taxa de conclusão das perguntas — as avaliações parciais recebem bandas mais largas
- Variância das respostas — extremos altos e baixos em pilares vizinhos sugerem cansaço de questionário
- Coerência do texto livre — quando uma explicação contradiz a pontuação de Likert, a confiança desce
A banda é mostrada na interface como um intervalo (p. ex. «68 ± 4») e é preservada nas exportações.
9.6 Referências setoriais
As referências são curadas a partir de investigação pública (relatórios de associações setoriais, estudos académicos, estatísticas publicadas por reguladores). Estão explicitamente identificadas na interface:
As referências setoriais são estimadas por IA e destinam-se apenas a orientação indicativa. O desempenho real do setor pode variar.
Nunca afirmamos que uma referência está atualizada — citamos o ano dos dados subjacentes.
9.7 Porque não usamos uma única «pontuação de confiança»
Algumas plataformas comprimem tudo num único número de 0 a 100 de «fiabilidade». Nós não. Um número único esconde o único sinal útil: que dimensão está a falhar. Uma organização pode ser Referência em estratégia e Retardatária em segurança ao mesmo tempo — isso é acionável. Fazer a média para «Perseguidor, 62» não é.
A nossa metodologia, dita com honestidade
A E-ARI pede a uma organização que classifique a sua própria preparação para a IA. A literatura publicada sobre autoavaliação é inequívoca quanto ao que isso pode e não pode medir, e esta página diz as duas coisas. Cada decisão de conceção abaixo nomeia a sua fonte.
O modelo de três níveis
- Autodeclarado — o questionário tal como foi respondido — uma medida de perceção, identificada como tal.
- Sustentado por provas — as respostas com artefactos no cofre — existência verificada, um limite inferior da preparação real.
- Verificado de forma independente — as respostas verificadas por um auditor ou pelo motor determinista face ao cofre de provas — funcionamento verificado. Ainda não oferecido.
Uma avaliação concluída mostra por isso três números, não um: a pontuação autodeclarada (identificada como «Autodeclarada — uma medida de perceção»), a pontuação sustentada por provas (identificada como «Sustentada por provas — apenas respostas com artefactos no cofre») e a quota de cobertura («X % das respostas estão sustentadas por provas»). Quando nenhuma resposta traz prova, a pontuação sustentada não é mostrada de todo — um número autodeclarado sem nada por trás não é uma segunda opinião, é a mesma opinião.
As respostas sem prova contam com metade do peso na pontuação sustentada. O 0,5 é uma escolha nossa, não uma constante da literatura. O que a investigação estabelece é a direção: as autoavaliações são indulgentes em cerca de um terço de desvio-padrão (d = 0,32; Heidemeier e Moser, 2009), e a aquiescência empurra para cima as respostas em escalas de concordância (Krosnick, 1999). Nenhuma delas nos dá um número. Reduzimos a metade aquilo que ninguém pode verificar, arredondamos de propósito para que não seja confundido com uma medição, e mostramos ao lado a quota de cobertura para que se veja sobre quanto da pontuação esse peso sequer atua. Descontar a perceção — e não apagá-la — é o que o modelo de níveis afirma.
A conceção com vários avaliadores
Uma única pessoa a responder às 40 perguntas é uma conceção de informante único. Conway e Huffcutt (1997) situam a fiabilidade entre avaliadores em ,50 para superiores, ,37 para pares e ,30 para subordinados — e a concordância ENTRE fontes ainda mais baixa, ,22 entre o próprio e o superior. Mesmo no melhor caso, metade da variância fica no avaliador e não na organização. O modo de vários avaliadores convida até quatro responsáveis funcionais — o diretor técnico para Tecnologia e Dados, o EPD para Governação e Segurança, o diretor de operações para Processos e Cultura, o diretor de pessoas para Talento e Estratégia — a responder apenas aos pilares que a sua função cobre. A pontuação de consenso é a resposta mediana por pergunta entre avaliadores, pontuada pelo mesmo motor determinista. As avaliações com um só avaliador são assinaladas como tal, com essa ressalva anexada.
A divergência entre avaliadores é um sinal, não um erro — indica onde os responsáveis funcionais têm visões diferentes da preparação da organização.
Não sei, não aplicável e o papel de quem responde
Uma escala de concordância de escolha forçada só oferece más opções a quem genuinamente não sabe. Os honestos escolhem «Discordo totalmente» — e o instrumento regista uma constatação que essa pessoa nunca fez: um défice de governação que é, na verdade, uma lacuna de conhecimento. As experiências de Schuman e Presser (1981) com filtros de «sem opinião» são o resultado clássico — os formulários de escolha forçada recolhem pseudo-opiniões de quem não as tem — citadas aqui apenas para a direção: essa fonte NÃO ESTÁ VERIFICADA DE FORMA INDEPENDENTE, e nenhum número dela é usado. A avaliação regista por isso duas anotações que uma resposta pode trazer em vez de uma classificação — Não sei e Não aplicável — e ambas ficam excluídas da aritmética de pontuação: o pilar renormaliza sobre as suas perguntas respondidas, pelo que um desconhecido nunca puxa uma pontuação para baixo nem a inflaciona. São antes mostradas como lacunas de cobertura — por pilar, «x de 5 respondidas», com as perguntas sem resposta nomeadas. Um pilar cujas perguntas estão todas anotadas é recusado por completo (E_NO_PILLAR_COVERAGE): uma pontuação calculada a partir de nenhuma medição não é uma pontuação. A renormalização é limitada pela mesma razão — pede emprestadas as perguntas respondidas para fazerem as vezes das que faltam — pelo que um pilar com menos de três das suas cinco perguntas classificadas também é recusado (E_INSUFFICIENT_PILLAR_COVERAGE), em vez de deixar duas respostas fazerem de pilar. Sem limite, a aritmética atingia o seu extremo com uma resposta classificada por pilar: oito em quarenta, todas no topo da escala, produziam um composto de 99,99 exatamente igual a um calculado sobre o instrumento inteiro. Os detetores X-Ray não disparam sobre uma pergunta anotada, pela mesma razão das recusas — o seu desencadeador não pode ser avaliado sobre dados que não existem — e um detetor que não pôde ser avaliado é reportado como tal, nunca como um que correu e nada encontrou. Esta é uma alteração de pontuação, não um acrescento de interface: uma avaliação que usa as anotações pontua de forma diferente de uma em que as mesmas perguntas são respondidas com 1. As anotações chegaram como SCORING_VERSION 5.5 e o limite da renormalização como SCORING_VERSION 5.6, cada um com vetores de conformidade rederivados; o limite não move qualquer pontuação, e as avaliações pontuadas sem anotações continuam idênticas bit a bit à 5.4.
«Avaliador único» é a versão grosseira de uma pergunta mais afiada: qual avaliador? Um diretor técnico que responde às 40 perguntas fala em primeira mão de Tecnologia e Dados e em segunda mão de Governação e Cultura, e o custo em fiabilidade não se reparte por igual (Conway e Huffcutt, 1997; a prática 360° de emparelhar avaliadores com os seus domínios é Bracken, Timmreck e Church, 2001). Cada avaliação regista por isso o papel funcional de quem responde, e os resultados nomeiam que pilares esse papel cobre em primeira mão — os de segunda mão são identificados como tal, para que um leitor veja onde a perceção é mais fina. O papel também semeia os convites a outros avaliadores: os papéis que quem responde não ocupa são os que vale a pena convidar.
O segundo instrumento: os construtos regulamentares
A auditoria de redesenho perguntou também que terreno regulamentar as 40 perguntas não cobrem de todo, e encontrou nove construtos: um inventário de sistemas de IA com as classificações do art. 6.º registadas, as obrigações de cadeia de fornecimento para prestadores e modelos de finalidade geral, a gestão de incidentes, o registo, as especificidades da supervisão humana, o acompanhamento pós-comercialização, a profundidade das métricas de enviesamento, e os ciclos de auditoria interna (9.2) e de revisão pela direção (9.3) da ISO/IEC 42001. Não são deliberadamente acrescentados ao instrumento pontuado — as 40 perguntas são metodologia congelada (SCORING_VERSION 5.6), e acrescentar perguntas reescreveria todas as avaliações alguma vez feitas. Formam antes um segundo instrumento: uma lista de verificação diagnóstica respondida com sim / não / parcialmente / não sei / não aplicável, onde não e parcialmente são lacunas abertas, não sei é uma lacuna de conhecimento, e não aplicável é registado e excluído. É reportado como diagnóstico e lacunas — nunca como pontuação. Que obrigações se aplicam é decidido pelo motor de conformidade; os itens remetem para os seus códigos de obrigação para mostrar sobre que dever uma lacuna faz pressão, nada mais.
Verificação ancorada no comportamento
Quando uma pergunta tem forma factualmente verificável («O seu plano de resposta a incidentes trata especificamente das falhas de sistemas de IA?» em vez de «Que maturidade tem a sua resposta a incidentes?»), a avaliação oferece as duas: o item de Likert original, que continua a ser a resposta pontuada por compatibilidade, e um controlo «Verificar esta resposta» com Sim/Não/Parcialmente. Um Sim verificado conta com peso total na pontuação sustentada por provas; a resposta de Likert não muda. Este é o padrão BARS: perguntar se algo concreto e observável é verdade em vez de que tal parece. Latham, Wexley e Pursell (1975) e Schwarz (1999) sustentam o mecanismo — o formato fixa o quadro de referência, e uma pergunta verificável é mais difícil de inflacionar do que uma global. Nenhum dos dois reporta uma redução percentual, e os «~40 %» que este documento antes afirmava não estavam em nenhum deles.
A investigação sobre enviesamentos em que isto assenta
- Podsakoff, MacKenzie e Podsakoff (2012). «Sources of Method Bias in Social Science Research and Recommendations on How to Control It.» Annual Review of Psychology 63, 539–569. — A variância de método comum — uma mesma pessoa a responder dos dois lados — inflaciona as relações observadas em construtos subjetivos. A revisão estabelece a direção e como desenhar contra ela; não dá uma percentagem única, e os «25–40 %» antes aqui indicados não tinham fonte.
- Kruger e Dunning (1999). «Unskilled and Unaware of It.» Journal of Personality and Social Psychology 77(6), 1121–1134. — Quem tinha desempenho no quartil inferior pontuava no percentil 12 e colocava-se a si próprio no 62 — 50 pontos, nas palavras do próprio artigo. As organizações menos equipadas para governar a IA são as que mais provavelmente se classificam alto, porque não conseguem ver que aspeto tem a maturidade.
- Heidemeier e Moser (2009). «Self–Other Agreement in Job Performance Ratings: A Meta-Analytic Test of a Process Model.» Journal of Applied Psychology 94(2), 353–370. — Em 128 amostras, a concordância entre o próprio e o superior é r = ,22 e as autoavaliações são indulgentes em d = 0,32 (Δ = ,49 corrigido) — cerca de um terço de desvio-padrão, não a metade antes aqui indicada.
- Latham, Wexley e Pursell (1975). «Training Managers to Minimize Rating Errors in the Observation of Behavior.» Journal of Applied Psychology 60(5), 550–555. — Os avaliadores a quem se pergunta por comportamentos observáveis concretos erram menos do que aqueles a quem se pede um juízo global. É um estudo sobre formação de avaliadores, não uma comparação entre BARS e Likert, e não reporta qualquer percentagem — os «~40 %» antes aqui indicados não estavam lá.
- Schwarz (1999). «Self-Reports: How the Questions Shape the Answers.» American Psychologist 54(2), 93–105. — O formato da pergunta fixa o quadro de referência: «Que maturidade tem a sua resposta a incidentes?» convida a um juízo global; «O seu plano de resposta a incidentes trata das falhas de sistemas de IA?» invoca um facto verificável.
- Krosnick (1999). «Survey Research.» Annual Review of Psychology 50. — A aquiescência — concordar independentemente do conteúdo — é uma ameaça conhecida aos itens em escala de concordância, e diminui quando as perguntas pedem factos em vez de adesão. Aqui não se atribui qualquer percentagem: os «~10–15 %» anteriores não tinham fonte, e um número dessa ordem não justificaria, de todo o modo, cortar uma resposta a meio. O desconto de 0,5 é a nossa própria escolha conservadora, descrita abaixo.
- Conway e Huffcutt (1997). «Psychometric Properties of Multisource Performance Ratings: A Meta-Analysis of Subordinate, Supervisor, Peer, and Self-Ratings.» Human Performance 10(4), 331–360. — A fiabilidade difere consoante a fonte: superiores ,50, pares ,37, subordinados ,30 — o ,50 é o melhor caso, não a média. A concordância entre fontes é ainda menor (o próprio face ao superior, ,22). Qualquer avaliador único deixa a maior parte da variância ligada ao avaliador, e é por isso que existem o modo de vários avaliadores e a marca de avaliador único. O ganho de fazer a média de vários avaliadores é Spearman-Brown, projeção nossa e não uma conclusão deste artigo.
- Van der Heijden e Nijhof (2004). «The value of subjectivity: problems and prospects for 360-degree appraisal systems.» International Journal of Human Resource Management 15(3), 493–511. — A divergência entre avaliadores de proveniências funcionais diferentes é em si um sinal diagnóstico válido — a base para reportar a divergência em vez de a diluir na média.
- Bracken, Timmreck e Church (2001). The Handbook of Multisource Feedback. Jossey-Bass. — A prática 360° estabelecida: os avaliadores respondem a conjuntos de perguntas emparelhados com o seu domínio de conhecimento, e o desacordo é reportado como constatação.
- Oxford Insights (2024). Government AI Readiness Index Methodology. — Recorre a fontes de dados verificáveis externamente sempre que possível e apresenta os dados de inquérito como «baseados em perceção» — o padrão de honestidade que as nossas etiquetas de nível seguem.
- Cisco (2024). AI Readiness Index Methodology. — Diz sem rodeios: «This is a perception study reflecting business leaders' views» — uma autoavaliação identificada como perceção, não como preparação objetiva.
O que podemos afirmar
- «A pontuação autodeclarada é uma medida de perceção — identificamo-la como tal»
- «A pontuação sustentada por provas conta apenas as respostas com artefactos no cofre — é um limite inferior da preparação real»
- «A quota de cobertura diz-lhe que parte da autoavaliação está sustentada por provas verificáveis»
- «O modo de vários avaliadores traz à superfície o desacordo entre responsáveis funcionais como sinal diagnóstico»
- «As respostas Não sei e Não aplicável são excluídas da pontuação e reportadas como lacunas de cobertura — nunca convertidas na pior resposta»
- «Cada avaliação regista o papel funcional de quem responde, e os resultados nomeiam de que pilares esse papel fala em primeira mão e de quais não fala»
- «O instrumento de construtos cobre nove áreas regulamentares que o instrumento pontuado não cobre, reportadas como diagnóstico e lacunas — nunca como pontuação»
O que continuamos sem poder afirmar
- «Uma pontuação E-ARI mais alta prevê o sucesso dos projetos de IA — não há dados de resultado»
- «O instrumento está validado de forma independente — não há estudo de validação publicado (exige mais de 50 organizações e 12 meses)»
- «A pontuação sustentada por provas equivale a conformidade auditada — verifica existência, não eficácia operacional»
O estudo de validação
A recolha de dados para um estudo de validação já começou. As organizações que consentiram recebem um instantâneo mensal das suas pontuações — autodeclarada, sustentada por provas, quota de cobertura, mapa de pilares, versão de pontuação — e o lado dos resultados é registado ao lado: eventos autodeclarados de projeto, incidente e auditoria, mais o próprio registo de acerto da contagem decrescente de conformidade, unidos às pontuações apenas no momento da análise. A retirada elimina os instantâneos e os resultados de uma organização. Nada disto muda uma afirmação: não existe qualquer número de validade, e a lista «o que continuamos sem poder afirmar» acima mantém-se inalterada até que um estudo sobre estes dados seja publicado. A prontidão do estudo é publicada como um contador — organizações e meses — onde quer que esta metodologia seja divulgada, para que a distância que falta percorrer seja dita em vez de insinuada.
Estes limites são estruturais. Quando o instrumento tiver dados de resultado, um estudo de validação publicado ou o aval de um auditor por trás de um nível, a linha correspondente passa de «não podemos» a «podemos» — e não antes.
10. Privacidade, segurança e tratamento de dados
10.1 O que guardamos
| Categoria | Exemplos | Onde |
|---|---|---|
| Dados de conta | Nome, email, organização, função, hash da palavra-passe | PostgreSQL (Supabase) |
| Respostas de avaliação | Respostas de Likert, desenvolvimentos em texto livre | PostgreSQL |
| Metadados de sistemas de IA | Nome do sistema, finalidade, setor, classificação | PostgreSQL |
| Documentos de prova | Ficheiros carregados (avaliações de impacto, contratos, fichas de modelo) | Vercel Blob (privado) |
| Artefactos gerados | Avaliações de impacto, documentações técnicas, relatórios | PostgreSQL + Vercel Blob |
| Registos | Registo de auditoria de conformidade, ações do utilizador | PostgreSQL, conservação de 90 dias |
| Pagamento | Identificador de cliente, plano de subscrição | Stripe (nunca guardamos números de cartão) |
10.2 Cifragem
- Em trânsito — TLS 1.3 em todo o lado, com pré-carregamento HSTS
- Em repouso — AES-256 (fornecido pelo Supabase e pelo Vercel Blob)
- Palavras-passe — bcrypt com fator de custo 12
10.3 Autenticação
- E-mail profissional e palavra-passe (fornecedor de credenciais do NextAuth). Os endereços de e-mail pessoais como Gmail, Outlook.com ou Yahoo são recusados no registo, no início de sessão e no convite para a equipa.
- SSO (OIDC) no plano Enterprise — configurado com o seu fornecedor de identidade (Okta, Entra ID, Google Workspace, Keycloak). Quando o SSO é imposto, a autenticação por palavra-passe é recusada e as sessões fora do SSO terminam, mesmo que o fornecedor de identidade esteja inacessível ou não registado; só um operador que desative a imposição restabelece o acesso por palavra-passe.
- Não há início de sessão com contas pessoais (Google, GitHub, X).
As sessões usam JWT com cookies HttpOnly, Secure e SameSite=Lax.
10.4 Localização dos dados
O cálculo está fixado a uma região da UE (Vercel, Frankfurt). A base de dados corre no Supabase (AWS eu-central-2, Zurique); a Suíça não é Estado-Membro da UE, mas beneficia de uma decisão de adequação da Comissão Europeia. O fornecedor de modelos predefinido trata os dados na China e outros subcontratantes ulteriores operam nas suas próprias regiões (ver /security#subprocessors), pelo que não afirmamos localização de dados exclusivamente na UE. As garantias para transferências transfronteiriças estão descritas no contrato de subcontratação.
10.5 Eliminação de dados
- A eliminação da conta é feita pelo próprio em
/portal/preferences - A eliminação é definitiva (não lógica) — em 30 dias são expurgados todos os dados da conta, incluindo ficheiros de prova, avaliações, avaliações de impacto e registos
- A conservação do registo de auditoria é independente e é expurgada ao fim de 90 dias, seja qual for o estado da conta
10.6 Postura face ao RGPD
- Contrato de subcontratação publicado em
/data-processing - Registo de subcontratantes ulteriores mantido em
/security#subprocessors - Direito ao apagamento cumprido em 30 dias
- Direito à portabilidade — exportação completa da conta em JSON a partir de
/portal/preferences
10.7 Utilização de modelos de linguagem de terceiros
O fornecedor de modelos predefinido da plataforma é a DeepSeek, que trata os dados na China; a China não beneficia de uma decisão de adequação da Comissão Europeia, pelo que as garantias de transferência têm de ser avaliadas. As funcionalidades assistidas por modelos são a geração de textos, a extração de cláusulas das evidências carregadas, a redação de conformidade e o enriquecimento de organizações; a pontuação de preparação e a classificação de risco por regras não usam qualquer modelo de linguagem. As condições de conservação e de treino seguem os termos de API do fornecedor: a E-ARI não afirma compromissos negociados de retenção nula ou de não treino, e não treina modelos próprios com dados de clientes. O texto das evidências enviado para extração de cláusulas passa primeiro por uma supressão de dados pessoais com expressões regulares.
11. Planos e preços
| Plano | Preço | Mais indicado para |
|---|---|---|
| Gratuito | 0 € | Registar sistemas e ver as obrigações aplicáveis |
| Pro | 299 €/mês ou 2.990 €/ano (poupa 17 %) | Governar sistemas: provas, FRIA e documentação técnica, registos verificáveis |
| Enterprise | A partir de 20.000 €/ano, acordado por contrato | Automatizar em escala: API, conectores, SSO e sem limites |
11.1 O que está incluído em cada plano
| Capacidade | Gratuito | Pro | Enterprise |
|---|---|---|---|
| Sistemas de IA | 3 | 25 | Ilimitados |
| Utilizadores que iniciam sessão | 2 | 10 | Ilimitados |
| Pessoas em formação de literacia no domínio da IA (Artigo 4.º) | 5 | 250 | Ilimitadas |
| Registo de sistemas de IA + classificação por regras | ✓ | ✓ | ✓ |
| Obrigações | As aplicáveis, com o artigo | Registo completo, com lacunas e ações | Registo completo, com lacunas e ações |
| Cofre de provas | 10 ficheiros | Ilimitado | Ilimitado |
| FRIA, documentação técnica, análise de lacunas + pacote de submissão | — | ✓ | ✓ |
| Exportações seladas e verificáveis | — | ✓ | ✓ |
| Ações de melhoria com revisão | ✓ | ✓ | ✓ |
| Relatório de literacia no domínio da IA do Artigo 4.º para toda a organização | — | ✓ | ✓ |
| Descoberta de IA fantasma (importações CSV) | — | Ilimitada | Ilimitada |
| Questionários de risco de fornecedores | — | 25 | Ilimitados |
| Despesa em IA e decisões de adoção | — | ✓ | ✓ |
| Órgãos de governação e verificação de entrada em produção | — | ✓ | ✓ |
| Política de IA publicada e confirmada | — | ✓ | ✓ |
| Registo de riscos e avaliações de impacto | — | ✓ | ✓ |
| Declaração de aplicabilidade ISO/IEC 42001 | — | — | ✓ |
| Avaliações de preparação por mês | 1 | 20 | Ilimitadas |
| Verificações de pulso por mês | 3 | 50 | Ilimitadas |
| Relatórios | 1 PDF por mês | Ilimitados, PDF e Word | Ilimitados + marca própria |
| Acesso à API (leitura e escrita) | — | — | ✓ |
| Conectores de provas | — | — | Acesso antecipado |
| SSO (OIDC) | — | — | ✓ |
| Apoio | Comunidade | Email (48 h) | Apoio dedicado, apoio em auditorias + SLA |
No roteiro e ainda não disponíveis: provisionamento SCIM, espaços de trabalho multientidade, controlos e referenciais personalizados, e recolha contínua de provas.
11.2 Cancelamento
Cancele quando quiser. O acesso mantém-se até ao fim do período de faturação. A conta volta automaticamente ao plano Gratuito — os seus dados são preservados, apenas perde o acesso às funcionalidades Pro.
12. A quem se destina
12.1 Três perfis principais
O responsável de programa de IA numa empresa de média dimensão (cerca de 500 a 5.000 colaboradores). Reporta ao diretor de operações ou de sistemas. É dono do roteiro da estratégia de IA. Precisa da E-ARI para:
- demonstrar progresso à direção, trimestre após trimestre
- traduzir lacunas de preparação em propostas de investimento concretas
- mostrar ao conselho que a empresa não está atrás dos seus pares
O EPD ou responsável de conformidade em qualquer organização que implante IA em jurisdições da UE. Precisa da E-ARI para:
- classificar automaticamente os sistemas de IA face ao Regulamento
- manter um cofre de provas vivo que sobreviva a uma auditoria
- gerar avaliações de impacto e documentações técnicas sem contratar uma grande sociedade de advogados
O auditor interno que prepara uma auditoria externa, uma certificação ISO 42001 ou a apreciação de um organismo notificado. Precisa da E-ARI para:
- produzir um único pacote de submissão com somas de verificação
- mostrar tendências de cobertura ao longo do tempo (ritmo de fecho de lacunas)
- fornecer registos à prova de adulteração de qualquer alteração a um artefacto
12.2 A quem não se destina
Sobre isto somos explícitos. A E-ARI não é a ferramenta certa se precisa de:
- um registo de modelos (use MLflow, Weights & Biases ou uma plataforma MLOps)
- uma ferramenta GRC generalista que abranja SOC 2, ISO 27001, HIPAA (use Vanta, Drata, Secureframe)
- aconselhamento jurídico (a E-ARI expõe obrigações; não substitui um advogado)
- gestão de projetos de entrega de IA (use Linear, Jira, Asana)
Quanto mais apertado o âmbito, melhor a ferramenta.
13. Roteiro
Focos atuais (sujeitos a alteração):
| Trimestre | Tema | Destaques |
|---|---|---|
| T2 2026 | Ecossistema de conectores — disponível | Conectores de provas para Slack, Jira, Confluence, Notion, GitHub, Google Drive, Microsoft 365, ServiceNow, Entra ID e Okta, com a maturidade indicada por conector |
| T3 2026 | Alinhamento com a ISO 42001 — disponível | Correspondência, nos dois sentidos, entre obrigações do Regulamento e controlos da ISO/IEC 42001 e do NIST AI RMF |
| T4 2026 | Multijurisdição | Quadro regulamentar britânico para a IA, decreto presidencial dos EUA, conformidade AEDT de Nova Iorque |
| T1 2027 | Fluxos com organismos notificados | Modelos de avaliação prévia de conformidade, pacotes automatizados de ligação ao organismo |
O roteiro é publicado na plataforma e atualizado todos os meses.
14. Glossário
Regulamento sobre a IA — Regulamento (UE) 2024/1689 do Parlamento Europeu e do Conselho que estabelece regras harmonizadas em matéria de inteligência artificial. Em vigor desde 1 de agosto de 2024.
Anexo III — A lista de casos de utilização de IA de risco elevado enumerados no anexo III do Regulamento (biometria, educação, emprego, serviços essenciais, aplicação da lei, migração, justiça).
Anexo IV — A estrutura da documentação técnica exigida para os sistemas de IA de risco elevado.
Artigo 5.º — Proíbe determinadas práticas de IA: manipulação subliminar, exploração de vulnerabilidades, classificação social, identificação biométrica à distância em tempo real em espaços públicos.
Artigo 27.º — Impõe uma avaliação de impacto sobre os direitos fundamentais para os sistemas de IA de risco elevado utilizados por autoridades públicas ou operadores de serviços essenciais.
Artigos 50.º a 53.º — Obrigações de transparência para os sistemas de risco limitado (chatbots, ultrafalsificações, categorização biométrica, reconhecimento de emoções).
Avaliação da conformidade — O procedimento pelo qual um sistema de IA de risco elevado demonstra o cumprimento dos requisitos do Regulamento antes de ser colocado no mercado da UE.
Responsável pela implantação — Qualquer pessoa singular ou coletiva, autoridade pública ou organismo que utilize um sistema de IA sob a sua autoridade. Distinto do prestador (a entidade que desenvolve o sistema ou o manda desenvolver).
AIPD — Avaliação de impacto sobre a proteção de dados, nos termos do artigo 35.º do RGPD. Muitas vezes um pré-requisito da avaliação de impacto sobre os direitos fundamentais.
AIDF — Avaliação de impacto sobre os direitos fundamentais, nos termos do artigo 27.º do Regulamento sobre a IA.
Modelo de IA de finalidade geral — Modelo de base. Sujeito a um regime de obrigações próprio nos artigos 51.º a 55.º.
Organismo notificado — Organismo designado por um Estado-Membro da UE para avaliar a conformidade de certos sistemas de IA de risco elevado antes da sua colocação no mercado.
Pilar — Uma das oito dimensões de preparação da E-ARI (Estratégia, Dados, Tecnologia, Talento, Governação, Cultura, Processos, Segurança).
Verificação de pulso — Uma avaliação mensal curta, dirigida às perguntas sensíveis ao desvio.
Pacote de submissão — A exportação .zip única que reúne documentação técnica do anexo IV, avaliação de impacto, provas e manifesto — pronta para um organismo notificado ou um auditor.
Documentação técnica — O dossiê exigido pelo anexo IV para os sistemas de IA de risco elevado. Tem de ser mantido atualizado durante toda a vida do sistema.
Anexo A — URL principais
| Superfície | URL |
|---|---|
| Sítio de marketing | https://www.e-ari.com |
| Preços | https://www.e-ari.com/pricing |
| Iniciar sessão | https://www.e-ari.com/auth/login |
| Portal | https://www.e-ari.com/portal |
| Casos de utilização (conformidade) | https://www.e-ari.com/portal/use-cases |
| Cofre de provas | https://www.e-ari.com/portal/evidence |
| Política de privacidade | https://www.e-ari.com/privacy |
| Termos de serviço | https://www.e-ari.com/terms |
| Estado e saúde | https://www.e-ari.com/api/health |
Anexo B — Contacto
| Assunto | |
|---|---|
| Questões gerais | hello@e-ari.com |
| Vendas / Enterprise | sales@e-ari.com |
| Privacidade / EPD | privacy@e-ari.com |
| Divulgação de vulnerabilidades | security@e-ari.com |
| Apoio | support@e-ari.com |
A E-ARI é operada pela equipa E-ARI. O cálculo da aplicação está fixado à UE (Vercel, Frankfurt); a base de dados corre no Supabase (AWS eu-central-2, Zurique). Este documento faz fé à data da versão indicada acima; a versão mais atual é sempre servida em https://www.e-ari.com/docs/e-ari-handbook.md.