O que você precisa saber
O documento RRIA será integrado ao processo de conclusão do HAS-IA e poderá registrar projeto, decisões, responsabilidades, dados, testes e limites demonstrados pelo participante. A emissão dependerá dos critérios finais. Não é ART, licença estatal, registro profissional obrigatório ou comprovação automática de conformidade.
- Documente uma versão específica do projeto e identifique o material necessário para revisá-la.
- Registre expectativas de teste, resultados observados e decisões sem preencher lacunas com suposições.
- Preserve falhas e mudanças de escopo para que o histórico continue compreensível.
- Um resumo público deve respeitar as permissões do material e não expor o dossiê inteiro.
Um dossiê para entender o projeto em determinada versão
O RRIA — Registro Responsável de Inteligência Artificial — está sendo estruturado para que uma pessoa consiga entender o objetivo, acompanhar as escolhas e conferir testes, dados e responsabilidades de um projeto de IA. A metodologia poderá apoiar exercícios da Genial Skills e projetos empresariais; os registros devem refletir o que foi realizado e identificar hipóteses, evidências e pendências.
O RRIA é um registro metodológico privado e não se confunde com ART, cadastro estatal, licença profissional ou auditoria independente. Um dossiê organiza a análise, mas não comprova automaticamente qualidade, conformidade ou aprovação do projeto. A equipe mantém a responsabilidade de verificar evidências e regras de publicação, validação e acesso.
Comece por um índice que localize as evidências
A primeira página deveria responder qual projeto está descrito e qual versão pode ser examinada. Use um nome compreensível, data da revisão e indicação do responsável pelo documento. Se o projeto ainda é uma hipótese ou exercício, registre esse estágio. Evite uma apresentação que faça um protótipo parecer uma implantação concluída.
O índice pode apontar para arquivos mantidos em um local autorizado. Não é necessário copiar toda evidência para um único documento. É necessário que a pessoa autorizada consiga encontrar a versão correta e entender eventuais restrições de acesso. Um link quebrado ou um arquivo substituído sem registro prejudica a revisão.
| Parte | O que registrar | Material de apoio |
|---|---|---|
| Finalidade | Tarefa, destinatário e usos fora do escopo | Briefing do projeto |
| Responsabilidades | Quem constrói, revisa e decide | Registro de decisões e aprovações pertinentes |
| Fontes | Origem, versão e condições de uso | Inventário de documentos e dados |
| Construção | Ferramentas, instruções e configurações relevantes | Versões do protótipo |
| Avaliação | Casos, expectativas e resultados | Registro de testes e falhas |
| Situação atual | Limites, pendências e próximo passo | Histórico de revisões |
Aprofunde este tema: HAS-IA: programa exclusivo Genial Skills para arquitetos de soluções com IA e registro RRIA →
Descrever fontes e componentes com contexto
Model Cards for Model Reporting, de Mitchell e colaboradores, propõe documentação sobre uso pretendido e avaliação de modelos. Datasheets for Datasets, de Gebru e colaboradores, propõe registrar características e contexto de conjuntos de dados. São referências para pensar a documentação; o RRIA proposto trata do projeto completo e não substitui esses documentos quando forem pertinentes.
No inventário de fontes, registre o que cada material sustenta, sua versão e as condições conhecidas de utilização. Se a origem ou a permissão estiver incerta, declare a pendência. Quando um documento muda, anote qual versão participou de cada teste. Isso permite distinguir uma mudança na solução de uma mudança no material consultado.
Na construção, identifique ferramenta, modelo quando essa informação estiver disponível, instruções e configurações relevantes. Se um serviço não expõe a versão exata, registre esse limite. Não invente um identificador para preencher o campo. Tampouco inclua senhas ou chaves de acesso: o dossiê deve indicar o processo autorizado de acesso, sem divulgar credenciais.
Separar o teste planejado do resultado observado
O NIST, no Playbook MEASURE 2.1, recomenda documentar conjuntos de teste, métricas e processos de avaliação. No modelo proposto, cada caso teria uma expectativa definida e um campo para o resultado real. Enquanto a execução não ocorrer, esse campo permaneceria pendente. A ausência de falha registrada não deve ser confundida com teste concluído.
Guarde os casos que falharam, inclusive depois da correção. Quando repetir um teste, identifique a versão avaliada e o que mudou. Se as condições do ambiente não puderem ser reproduzidas, descreva a limitação. O objetivo é tornar a comparação possível e explicar por que uma conclusão permanece incerta.
| Campo | Exemplo ilustrativo | Como preencher após testar |
|---|---|---|
| Situação | Comparação com uma página ausente | Identificar os arquivos e a versão usados |
| Expectativa | Sinalizar que a comparação está incompleta | Preservar a expectativa definida previamente |
| Resultado | Pendente: teste não executado | Registrar a saída observada e sua evidência |
| Decisão | Pendente de análise | Explicar correção, novo teste ou limitação aceita |
Registrar decisões com responsáveis e motivos
Uma alteração de escopo pode ser tão importante quanto uma melhoria do protótipo. Se o projeto deixa de recomendar uma ação e passa apenas a apresentar diferenças, registre o motivo. A decisão pode ter surgido de uma falha, de uma dúvida sobre fontes ou de uma necessidade da pessoa que recebe o resultado.
O Playbook do NIST, em GOVERN 2.1, trata da documentação de papéis e responsabilidades. No dossiê proposto, isso se traduziria em identificar quem preparou uma alteração, quem a revisou e quem tinha autoridade para decidir no contexto do projeto. Uma sugestão ainda não aceita deve continuar identificada como sugestão.
Um histórico curto que continua útil
Para cada revisão, anote data, versão, mudança, motivo e evidência relacionada. Evite substituir o relato anterior por uma história em que tudo parece ter funcionado desde o início. Quando houver uma correção no próprio documento, identifique o que foi retificado para que a pessoa que recebeu uma versão anterior consiga compreender a diferença.
Exemplo ilustrativo: um comparador de procedimentos
Considere um exercício com dois procedimentos de compras inteiramente fictícios. O resumo do dossiê poderia declarar: finalidade de localizar mudanças para revisão; entrada formada pelos dois documentos; saída esperada composta por diferenças, trechos de apoio e dúvidas; aprovação de compras e alteração de sistemas fora do escopo. Esse texto descreve a intenção, sem afirmar que ela foi demonstrada.
A pasta de evidências conteria o briefing, os documentos fictícios, a instrução usada e o registro de testes. Caso nenhum teste tenha sido executado, o estado seria preparação. Depois da execução, seriam incluídos resultados reais do exercício. Uma eventual falha em reconhecer documento incompleto deveria permanecer no histórico, junto com a decisão de corrigir ou limitar o protótipo.
O exemplo não descreve um cliente, produto pronto ou resultado obtido pela Genial Labs. Ele mostra como manter intenção, execução e conclusão em campos diferentes. A avaliação proposta do HAS-IA poderia usar esse material para discutir aprendizagem; as regras finais dessa avaliação ainda precisariam ser definidas.
Compartilhar um resumo e manter o trabalho atualizado
Um eventual portfólio pode apresentar problema, abordagem, critérios e limitações com exemplos fictícios ou materiais permitidos. O dossiê de trabalho pode exigir acesso restrito. Defina o público de cada versão e revise anexos, trechos de documentos e dados pessoais antes de compartilhar. O modelo não pressupõe publicação de todos os campos ou criação de uma base pública de projetos.
A atualização deveria acompanhar mudanças relevantes: nova fonte, alteração de instrução, troca de componente, ampliação de uso ou falha descoberta. Escolha quem revê o documento e como registra a situação atual. Para projetos reais, acesso, guarda e descarte de evidências dependeriam das condições aplicáveis ao trabalho e das decisões autorizadas.
Comece pelo que falta para outra pessoa entender sua entrega hoje. O artigo de avaliação HAS-IA complementa os critérios, e o guia de testes aprofunda a análise do sistema. A lista de espera RRIA, vinculada à Genial Skills, recebe interessados no programa em desenvolvimento; não oferece registro estatal, validação automática ou emissão já disponível.
