Definindo a tarefa e os requisitos técnicos do sistema de IA: NIST AI RMF Map 2.1

O NIST AI Risk Management Framework (AI RMF) foi concebido como um quadro voluntário aplicável a qualquer organização envolvida na conceção, desenvolvimento, implementação ou utilização de sistemas de inteligência artificial. Não é um requisito de conformidade obrigatório da mesma forma que alguns regulamentos o são (por exemplo, a Lei de IA da UE). No entanto, oferece diretrizes muito úteis - pense nele como um guia para ajudar a sua organização a garantir que os benefícios da IA são realizados de forma responsável.

Do que trata o Map 2.1?

A tarefa do seu sistema de IA está claramente definida? Evite estas armadilhas comuns ao alinhar-se com o NIST AI RMF 2.1:

1. A definição é demasiado vaga

“O sistema aprenderá a melhorar a satisfação do cliente.” Como medirá a melhoria? Que ações o sistema de IA tomará?

A IA aprenderá a reduzir os tempos de espera dos clientes no suporte telefónico, prevendo o volume de chamadas e analisando o tipo de chamada esperado e otimizando o agendamento dos agentes.

2. O âmbito é demasiado ambicioso

“O sistema resolverá todos os nossos problemas de atendimento ao cliente.”

Sério?

3. Ignorar pressupostos e limitações (relacionados com os dados, ambiente ou comportamento do utilizador)

Pressupostos ocultos podem levar a falhas inesperadas. Limitações não são falhas.

Pressupostos:

• O histórico médico e os sintomas do paciente são registados com precisão no registo de saúde eletrónico.
• As imagens utilizadas para diagnóstico são de qualidade e resolução suficientes.
• A linguagem utilizada em e-mails de spam será predominantemente as línguas em que o filtro foi treinado. Limitação: O sistema pode ter dificuldades com perguntas que exigem uma compreensão matizada de sarcasmo ou humor.

4. Especificações e requisitos técnicos não estão claramente definidos

A IA deve ser rápida e precisa. O sistema de deteção de fraude alimentado por IA deve atingir uma pontuação F1 mínima de X num conjunto de dados de teste reservado de pelo menos Y transações. O sistema deve ser capaz de lidar com um volume de transações de até Z transações por segundo.

5. Nenhuma documentação de desenvolvimento, teste, métricas e desempenho

O sistema foi treinado num grande conjunto de dados e testado extensivamente. O sistema de tradução foi desenvolvido usando a arquitetura X. Os dados de treino consistiram em textos paralelos em inglês e espanhol, provenientes de conjuntos de dados publicamente disponíveis e do nosso corpus interno. Empregámos a pontuação BLEU como a métrica de avaliação primária. O sistema alcançou uma pontuação BLEU média de 0,85 no conjunto de teste.

6. Nenhuma referência às suas práticas de gestão de dados baseadas na responsabilização

A nossa organização adere aos Princípios de Privacidade da OECD. Implementámos as seguintes práticas de gestão e proteção de dados: …

7. Nenhum alinhamento das especificações com metas e objetivos

As especificações técnicas para o sistema incluem rastreamento de inventário em tempo real com 99% de precisão e pedidos automatizados com base em limites predefinidos e otimizados para custo e tempo de entrega. Estas especificações apoiam diretamente os objetivos de reduzir as ruturas de stock e minimizar o desperdício, permitindo uma previsão de procura mais precisa, melhor visibilidade do inventário e processos de pedido otimizados.

Reveja estes pontos: ao definir clara e estritamente as tarefas do seu sistema, torna mais fácil mapear benefícios e riscos, o que melhora a gestão de risco.