Caderno de encargos para projeto de IA: modelo do operador

Um caderno de encargos útil para um projeto de IA é um contrato de aceitação, não uma lista de ferramentas. Descreve o problema de negócio e a situação inicial observável, o fluxo incluído, as exclusões explícitas, as entradas permitidas e as fontes com autoridade. Define a saída esperada e os testes que permitem aceitá-la. Identifica também quem aprova o resultado, as evidências e registos a conservar, os casos que interrompem o fluxo e a pessoa responsável pelo documento. A última parte fixa uma data de revisão e uma decisão clara: implementar, rever ou parar. Um fornecedor pode então propor a execução sem alterar discretamente o significado de sucesso.

Por que razão é preciso um contrato de aceitação?

Uma lista de modelos, ligações e funcionalidades descreve uma compra desejada, não o que o projeto tem de provar. O contrato coloca o resultado observável em primeiro lugar. Negócio, equipa técnica e fornecedor passam a inspecionar a mesma fronteira.

O documento não tem de antecipar toda a implementação. Tem de tornar divergências visíveis. Uma entrada proibida fica registada. Se duas fontes aprovadas se contradisserem, o caso para. Uma saída sujeita a aprovação continua a ser um rascunho, mesmo quando o ecrã parece acabado.

O NIST AI Risk Management Framework é voluntário e destina-se a ajudar organizações a incorporar considerações de confiança no desenho, desenvolvimento, uso e avaliação de sistemas de IA. O seu núcleo usa Govern, Map, Measure e Manage. O Playbook apresenta ações voluntárias sugeridas e não é uma checklist nem uma sequência obrigatória. Este modelo editorial é independente e não alega certificação, conformidade ou suficiência jurídica.

Quais são as sete partes a copiar?

Copie estes sete títulos e exija uma resposta concreta sob cada um. Uma resposta vazia, vaga ou contestada mostra que esse ponto não está pronto para aceitação.

1. Problema e situação inicial observável. Descreva o problema sem nomear uma solução. Registe o que é observável agora e como será feita a mesma observação na revisão.
2. Fluxo incluído e exclusões. Nomeie o evento inicial, o ponto final, pessoas ou sistemas envolvidos e tudo o que o projeto não pode fazer.
3. Entradas permitidas e autoridade. Liste formatos e repositórios. Indique a fonte que prevalece e imponha uma paragem quando falta autoridade ou existem contradições.
4. Saída e critérios de aceitação. Defina campos, estrutura, língua, referências, conteúdo proibido e condições de aprovação ou rejeição.
5. Conjunto de testes. Inclua casos normais, incompletos, ambíguos, contraditórios e sensíveis, cada um com comportamento esperado.
6. Aprovação, falha, paragem e evidências. Identifique o ponto de decisão e a via de paragem. Defina versões, fontes, decisões, exceções e correções conservadas.
7. Responsável e revisão. Atribua a manutenção de regras, fontes e testes, fixe uma data e registe implementar dentro da fronteira testada, rever ou parar.

O guia prático da France Num recomenda formalizar objetivos, funções e regras, testar antes da implementação, manter supervisão humana em tarefas sensíveis, assegurar rastreabilidade e manter instruções, configuração e documentos. Trata-se de orientação prática, não de lei vinculativa.

Que tabela pode servir de documento de trabalho?

Cada linha corresponde a uma decisão que deve produzir uma evidência inspecionável.

Como se constrói o conjunto de testes?

Teste a fronteira e a recusa, não apenas o caso normal bem apresentado. Cada caso inclui entrada, saída ou paragem esperada, resultado real, revisor e decisão.

• Normal: entrada completa e permitida, apoiada por fonte com autoridade.
• Incompleto: falta um dado ou uma fonte; a lacuna é assinalada e não inventada.
• Ambíguo: há mais de uma leitura; pede-se decisão humana.
• Contraditório: fontes permitidas divergem; o conflito é mostrado e o fluxo para.
• Sensível: o caso pertence à categoria sensível definida ou sai do âmbito; não ocorre ação não autorizada.

Quando há tratamento de dados pessoais, a CNIL enquadra o trabalho em torno da definição da finalidade, das responsabilidades e da base jurídica, da proteção dos direitos dos titulares, da minimização e controlo dos dados e de medidas de segurança. Estes projetos requerem análise jurídica e de privacidade adequada; o modelo não é aconselhamento jurídico nem comprova conformidade com o RGPD.

Como fica um exemplo fictício preenchido?

Este fluxo interno de encaminhamento de pedidos é hipotético e não promete produtividade.

1. Problema. Pedidos internos chegam a uma caixa partilhada. Uma amostra datada contém texto, categoria escolhida por uma pessoa e equipa de destino.
2. Âmbito. Começa com o pedido interno e termina numa proposta de encaminhamento. Não responde, altera registos, atribui trabalho ou processa pedidos externos.
3. Entradas. São permitidos texto, lista aprovada de categorias e diretório aprovado. O diretório controla nomes de destino. Se faltar categoria ou destino, o fluxo para.
4. Saída. O rascunho contém identificador, categoria e destino propostos, entrada citada do diretório e razão curta. Todos os campos e apoio nas fontes são necessários.
5. Testes. Incluem um pedido claro de instalações, outro sem local, uma formulação que pode significar acesso ou equipamento, fontes que apontam para equipas diferentes e um pedido sensível. Esperam-se rascunho, paragem por falta, decisão humana, paragem por conflito e paragem sensível.
6. Aprovação. A coordenação aceita, edita ou rejeita. Casos incompletos, ambíguos, contraditórios, sensíveis ou externos não são encaminhados. Conservam-se versões, rascunho, decisão, exceção e correção.
7. Responsável. Operações mantém categorias, diretório e testes. A revisão datada decide implementar dentro da fronteira, rever ou parar.

Este artefacto é mais concreto do que o exemplo geral de projeto de inteligência artificial. Para escolher primeiro o fluxo, consulte como automatizar uma empresa com IA.

Que sinais revelam uma lista de desejos?

O caderno falha quando descreve o produto com precisão e a aceitação de forma vaga.

• começa por uma plataforma, não pelo problema;
• abrange um departamento sem exclusões;
• fala em «dados da empresa» sem fontes nem autoridade;
• pede qualidade sem formato nem critérios;
• testa apenas exemplos favoráveis;
• menciona revisão humana sem revisor ou decisão;
• pede registos sem definir evidências;
• não estabelece paragem e entrega a uma pessoa;
• ninguém mantém fontes, testes e data de revisão.

Quando se deve implementar, rever ou parar?

A decisão é curta porque as evidências já estão definidas.

• Implementar: os testes têm resultados inspecionáveis, os critérios são cumpridos, as paragens funcionam, existe aprovação humana e o responsável aceita apenas a fronteira testada.
• Rever: o problema continua válido, mas falta uma regra, entrada, fonte, critério, teste ou via de aprovação. Altera-se o contrato e testa-se novamente.
• Parar: não se estabelecem entradas ou autoridade, a saída não pode ser julgada, a paragem falha ou ninguém assume responsabilidade.

Implementar não alarga o âmbito. Nova entrada, fonte, saída ou ação altera o contrato e exige testes e revisão.

Perguntas frequentes

Como redigir o caderno? Como contrato de aceitação com base, âmbito, entradas, saída, testes, aprovação, paragens, evidências e responsável.

Quais são os componentes? Sete partes: problema; âmbito; fontes; saída; testes; aprovação, paragens e evidências; manutenção e revisão.

Quais são as etapas? Escrever, preparar casos, testar no âmbito, rever evidências e decidir implementar, rever ou parar.

Comprova conformidade? Não. Segundo a CNIL, projetos com dados pessoais requerem análise jurídica e de privacidade adequada.