Capítulo 5 de 6
Percorra os conceitos em uma trilha visual. Depois, use o laboratório e abra o conteúdo completo para aprofundar.
Você está aqui: conceitos essenciais → exemplo → interação → leitura detalhada
Trilha interativa
Organize problema, pessoas, dados, alternativas, implantação e valor público antes de escolher uma solução.
A tecnologia precisa responder a um problema institucional observável.
Exemplo: reduzir tempo de triagem é um problema; classificar documentos é uma tarefa possível.
Qual mudança será percebida por quem usa o serviço?
Uma hipótese deve ligar a intervenção a uma mudança e a um valor público verificável.
Exemplo: uma sugestão mais rápida só tem valor se reduzir retrabalho sem aumentar erros relevantes.
Qual evidência confirmará ou enfraquecerá a hipótese?
Quem usa o sistema não é necessariamente quem suporta seus efeitos.
Exemplo: inclua servidores, magistratura, partes, advogados e pessoas que dependem de canais alternativos.
Quem pode ser afetado sem estar na tela?
Uma regra, uma melhoria de processo ou uma linha de base podem resolver melhor o problema.
Exemplo: padronizar um formulário pode ser mais barato e explicável do que treinar um classificador.
O que acontece se não usarmos ML?
A coleta precisa ter finalidade, base, segurança e representatividade adequadas.
Exemplo: dados públicos continuam exigindo análise de contexto, minimização e proteção.
Qual dado é necessário e qual pode ser excluído?
A saída deve chegar a uma ação humana definida, com possibilidade de abstenção e correção.
Exemplo: baixa evidência pode encaminhar o caso para revisão em vez de sugerir uma classe.
Quem decide depois da saída e pode discordar dela?
Sucesso inclui qualidade, impacto, equidade, acessibilidade e uma condição de não implantação.
Exemplo: um ganho de velocidade não compensa um erro grave sem mitigação.
Qual resultado faria interromper o projeto?
Portões progressivos permitem aprender sem expor imediatamente o fluxo real.
Exemplo: no modo sombra, compare a sugestão com a decisão humana sem alterar o processo.
Qual evidência autoriza avançar para o próximo portão?
Um projeto sustentável registra responsabilidades, dependências, portabilidade e continuidade.
Exemplo: o Canvas torna visíveis usuários, dados, sucesso, riscos e responsáveis.
Quem consegue explicar, operar, auditar e interromper a solução?
Como usar: percorra a trilha, observe o exemplo e use o laboratório abaixo para testar o conceito com dados sintéticos.
Próxima etapa
As simulações ficam em páginas próprias para você se concentrar em uma atividade por vez.
Seu progresso fica somente neste dispositivo.
Nos quatro primeiros capítulos, percorremos fundamentos, modelos preditivos, visão computacional e Processamento de Linguagem Natural. Aprendemos a distinguir tarefa de decisão, avaliar dados e erros, acompanhar falhas de OCR e verificar a fidelidade de resultados textuais. Agora reuniremos esses conhecimentos em uma pergunta anterior à escolha do modelo: qual problema institucional merece ser enfrentado e como saberemos se a proposta produz valor público?
Um projeto frágil costuma começar com uma tecnologia: “vamos usar inteligência artificial generativa”, “precisamos de um classificador” ou “o tribunal deve ter um chatbot”. O nome da ferramenta ocupa o lugar da necessidade, e a equipe só depois procura dados e usos que a justifiquem. O caminho responsável é inverso. Primeiro se descrevem o processo atual, a evidência do problema, as pessoas envolvidas, as alternativas e as consequências dos erros. Somente então se define se há uma tarefa computacional útil e se o aprendizado de máquina (ML) acrescenta valor.
Neste capítulo, construiremos um Canvas de projeto de IA, isto é, um quadro sintético e revisável que conecta problema, atores, alternativas, dados, tarefa, sucesso, implantação e condição de parada. O Canvas não é autorização para desenvolver nem substitui análises jurídicas, de segurança, proteção de dados ou risco. Sua função é tornar hipóteses explícitas antes que tempo, orçamento e expectativas se cristalizem em uma solução.
Ao final deste capítulo, você deverá ser capaz de:
💬 Pra começo de conversa!
Uma unidade recebe milhares de documentos e relata demora na triagem. Um fornecedor oferece um classificador “com 95% de acurácia”. Antes de contratar, o que falta saber?
Ainda não conhecemos os cinco tipos documentais, a frequência de cada classe, o tempo atual, a origem dos rótulos, o custo de cada erro, o desempenho humano, a possibilidade de melhorar formulários, a forma de revisão nem quem será afetado pelo roteamento. O percentual isolado não demonstra que o problema foi compreendido - e muito menos que a solução é adequada.
Esses três níveis respondem a perguntas diferentes:
| Nível | Pergunta | Exemplo |
|---|---|---|
| Problema institucional | Que dificuldade pública observável existe? | A triagem manual de cinco tipos documentais consome tempo e gera retrabalho. |
| Tarefa computacional | Que transformação de informação poderia ajudar? | Sugerir uma classe para cada documento e abster-se em casos incertos. |
| Solução sociotécnica | Como processo, pessoas e tecnologia atuarão em conjunto? | Formulário revisado, classificador, interface de confirmação, fila de exceções, treinamento e monitoramento. |
“Classificar documento” não é o benefício final. A classificação só poderá reduzir tempo ou retrabalho se a saída chegar no momento adequado, for compreendida, puder ser corrigida e produzir uma ação compatível com o fluxo. Uma previsão tecnicamente boa pode falhar por interface confusa, infraestrutura indisponível ou incentivo para aceitar sugestões sem revisão.
Uma formulação útil do problema contém:
Compare “queremos usar IA na triagem” com “entre janeiro e março, a unidade mediu o tempo entre recebimento e confirmação de cinco tipos documentais; deseja reduzir retrabalho sem aumentar encaminhamentos incorretos, mantendo confirmação humana”. A segunda redação é testável e permite concluir que outra solução pode ser melhor.
📝 Tome nota!
Um bom enunciado do problema permanece válido mesmo que a hipótese de usar ML seja rejeitada.
Relatos profissionais ajudam a localizar uma dificuldade, mas não bastam para dimensioná-la. A equipe pode combinar observação do fluxo, amostra de casos, registros do sistema, entrevistas, tempos de execução, retrabalho, filas e reclamações. É preciso registrar período, unidade, método e limitações. Uma média global pode esconder picos, classes raras ou concentração da demora em grupos específicos.
Em seguida, constrói-se uma teoria de mudança: uma cadeia de hipóteses que explica como recursos e alterações de processo produziriam benefício público.
classificador + interface + capacitação
↓
sugestão revisável no ponto de triagem
↓
menos tempo e retrabalho, sem elevar erro relevante
↓
fluxo mais tempestivo e acessível às pessoas afetadas
Cada seta precisa de evidência. O modelo pode sugerir corretamente, mas a interface não ser usada; o tempo pode cair, mas a correção aumentar; a unidade pode acelerar uma etapa que apenas transfere a fila para outra. A teoria deve incluir mudança de fluxo, capacitação, suporte e supervisão - não apenas o componente técnico.
💡 Para refletir!
Se a tarefa for executada perfeitamente, qual hipótese ainda pode impedir o benefício institucional?
Descrição acessível: Fluxo em seis etapas, do problema medido ao valor público, com perguntas de verificação entre tarefa, solução sociotécnica, saída operacional, resultado institucional e benefício comprovado.
Usuário é quem opera, consulta ou mantém a ferramenta. Pessoa afetada é quem sofre efeito direto ou indireto, ainda que nunca veja a interface. No exemplo, um servidor confirma a classe; uma equipe técnica mantém o serviço; a advocacia pode perceber um encaminhamento; a parte pode sofrer atraso ou correção. Gestores, órgãos de controle, fornecedores e equipes de atendimento também têm necessidades e poderes diferentes.
| Ator | Necessidade ou interesse | Forma de participação | Risco a observar |
|---|---|---|---|
| usuário interno | clareza e ganho real no trabalho | testar, corrigir e relatar | aceitação automática ou carga adicional |
| pessoa afetada | tratamento tempestivo e justo | informar experiência e contestar | erro invisível ou demora concentrada |
| gestor | valor público e continuidade | decidir recursos, expansão ou suspensão | meta estreita de produtividade |
| equipe técnica | dados, requisitos e manutenção | desenvolver, testar e monitorar | dependência de componentes e acesso insuficiente |
| controle e proteção de dados | evidências e conformidade | revisar documentação e impactos | falta de logs, acesso ou responsáveis |
O mapa deve ser produzido cedo e revisto quando a integração mudar. Um classificador de apoio pode ganhar efeito material se passar a encaminhar automaticamente documentos. Atores antes periféricos podem tornar-se diretamente afetados.
Eficiência que cria barreira de acesso não constitui sucesso. O projeto deve considerar linguagem simples, tecnologia assistiva, deficiência, conectividade, alfabetização digital e atendimento humano. Interface acessível não é apenas contraste ou tamanho de fonte: inclui navegação por teclado, rótulos compreensíveis, leitura por tecnologia assistiva, tempo suficiente e mensagens de erro acionáveis.
Também se deve preservar canal alternativo quando a via digital não for adequada. Se a proposta depende de formulário padronizado, por exemplo, é preciso prever documentos produzidos com tecnologia assistiva, digitalizações, anexos excepcionais e atendimento a quem não consegue usar o canal principal. A equipe e os testes precisam incluir perspectivas diversas. A Resolução CNJ nº 615/2025 orienta diversidade, representatividade e interdisciplinaridade na composição das equipes e nas etapas do ciclo de vida.
Antes de construir um modelo, teste se o problema pode ser reduzido por:
IA não deve compensar indefinidamente um processo mal desenhado. Uma regra pode ser preferível quando os critérios são estáveis, explícitos e auditáveis. Um formulário pode deslocar a identificação do tipo para a origem, com validações. A resposta pode combinar medidas: formulário para casos regulares, regra para padrões claros e modelo apenas para exceções autorizadas.
Linha de base é a referência contra a qual o projeto será comparado. Inclui o processo atual e, quando pertinente, uma solução simples. Para a triagem, devem-se medir tempo, volume, correção, retrabalho, variação entre unidades e desempenho por classe. Depois, uma regra ou modelo clássico pode formar outra base de comparação.
Sem linha de base, “90% de precisão” não informa se houve ganho. O processo humano poderia atingir resultado superior; o erro poderia estar concentrado na classe mais sensível; ou a economia técnica poderia ser anulada pelo tempo de conferência.
⚠ Atenção!
Alternativa sem ML não é etapa protocolar para justificar uma escolha já feita. Ela pode ser a decisão final.
Um inventário inicial de dados deve responder:
| Dimensão | Perguntas mínimas |
|---|---|
| origem e período | De qual sistema, unidade e intervalo vêm os registros? |
| finalidade | Por que cada campo é necessário à tarefa? |
| hipótese jurídica | Qual fundamento autoriza cada operação de tratamento? Quem validará a análise? |
| proteção | Há dado pessoal, dado sensível, segredo de justiça ou outro sigilo? |
| seleção | Quais casos entram ou ficam fora? Que ausências isso produz? |
| rótulo | Quem definiu a classe, com qual instrução e possibilidade de divergência? |
| representatividade | Unidades, períodos, formatos e grupos relevantes estão cobertos? |
| ciclo | Quem acessa, por quanto tempo, onde se armazena e como se elimina? |
A finalidade vem antes da disponibilidade. O fato de um dado estar no processo ou ser acessível não o torna automaticamente necessário para treinamento. A Lei Geral de Proteção de Dados Pessoais (LGPD) exige, entre outros princípios, finalidade, adequação, necessidade, qualidade, transparência, segurança, prevenção, não discriminação e responsabilização. A definição da hipótese jurídica e das medidas aplicáveis deve envolver as áreas competentes; o Canvas registra a análise e suas pendências, mas não a presume.
Representatividade também depende do uso pretendido. Uma base de uma unidade, em um período estável e com documentos nativamente digitais pode não representar outras unidades, mudanças de sistema ou acervos digitalizados. Os capítulos anteriores mostraram que OCR, formatos e práticas de registro alteram a entrada. A análise deve comparar cobertura, ausências e qualidade por condições relevantes, sem expor dados protegidos.
A ficha do conjunto de dados documenta motivação, composição, coleta, pré-processamento, usos, distribuição e manutenção (GEBRU et al., 2021). Ela não transforma uma base inadequada em adequada; permite que limites e responsabilidades sejam examinados.
A tarefa precisa caber em uma frase operacional. Defina:
No caso sintético, a entrada pode ser texto e layout autorizados; a saída, sugestão de um dos cinco tipos, probabilidade estimada e trecho indicativo. Baixa evidência, formato desconhecido ou múltiplos tipos acionam abstenção. O servidor confirma ou corrige antes de qualquer roteamento. “Há humano no circuito” é insuficiente: é preciso prever tempo, fonte, competência, registro e possibilidade real de discordar.
O sucesso deve refletir a teoria de mudança, não apenas o modelo.
| Camada | Exemplos de indicadores |
|---|---|
| técnica | macro-F1, sensibilidade por classe, calibração, robustez e abstenção |
| operacional | tempo, retrabalho, disponibilidade, fila e correções |
| jurídica | aderência à finalidade, supervisão, rastreabilidade e contestação |
| humana e acessível | compreensão, carga, autonomia, satisfação e barreiras de acesso |
| distributiva | erros, abstenções, tempo e benefícios entre condições ou grupos relevantes |
| econômica e institucional | custo total, interoperabilidade, portabilidade e continuidade |
Cada indicador precisa de fonte, período, população, linha de base, limite e frequência de revisão. Macro-F1 dá peso igual às classes e ajuda quando as frequências diferem, mas não substitui a sensibilidade da classe cujo falso negativo seja grave. Calibração permite interpretar probabilidades estimadas; taxa de abstenção mostra quanto trabalho o sistema devolve. Nenhuma dessas medidas demonstra sozinha benefício público.
Métricas operacionais evitam otimizar o componente errado. Se a correção da sugestão leva mais tempo que a triagem manual, o desempenho do modelo não se converte em ganho. Se a fila fica menor na entrada e maior na revisão, houve deslocamento, não solução.
Critérios distributivos procuram concentração de efeitos. Não se deve inferir que a média representa todas as unidades, formatos, canais ou grupos. A escolha das comparações exige justificativa contextual, proteção de dados e análise jurídica; não se resume a uma lista universal de atributos.
Erros têm consequências assimétricas. Para cada classe e ação, pergunte:
A equipe deve escrever antes do piloto condições de não implantação ou interrupção: desempenho inferior à linha de base em classe crítica; ausência de base jurídica; impossibilidade de revisão ou correção; barreira de acessibilidade; segurança insuficiente; custo total desproporcional; ganho operacional irrelevante; ou dano concentrado sem mitigação adequada.
Essa decisão antecipada reduz o risco de manter o projeto apenas porque já houve investimento.
Produto mínimo viável (MVP) é a menor configuração capaz de testar a hipótese principal com risco controlado. “Mínimo” não significa sem documentação ou segurança. A progressão recomendada é:
No teste offline, saídas são comparadas com referências sem integrar o modelo ao fluxo. No modo sombra, o sistema recebe entradas do ambiente e registra sugestões, mas elas não afetam o trabalho. Isso revela latência, falhas de integração e mudança de distribuição, embora ainda não meça plenamente confiança e comportamento quando a sugestão fica visível.
O piloto introduz uso real em escopo delimitado. Deve fixar unidade, duração, população, treinamento, suporte, responsáveis, comunicação, indicadores, critérios de saída e rollback - o retorno seguro ao processo ou versão anterior. A expansão depende de evidência; não é continuação automática do cronograma.
Descrição acessível: Sequência da linha de base à expansão controlada, com portões após teste offline, modo sombra e piloto. Cada portão permite prosseguir, ajustar ou encerrar, e as fases integradas admitem retorno seguro.
Estruturar o projeto exige conhecimentos sobre processo, Direito, dados, engenharia, segurança, proteção de dados, acessibilidade, contratação, auditoria e experiência das pessoas afetadas. A Resolução CNJ nº 615/2025 determina orientação à diversidade, representatividade e interdisciplinaridade das equipes e inclui participação nas etapas técnicas e negociais, tanto quanto possível.
Papéis devem ser nomeados: responsável pelo produto, área demandante, responsável técnico, validação jurídica, proteção de dados, segurança, acessibilidade, operação, monitoramento e autoridade para suspender. Um comitê genérico não substitui responsáveis por decisões concretas.
Documentos mínimos evoluem com o projeto:
Cartões de modelo descrevem uso pretendido, avaliação, desempenho e limitações em condições relevantes (MITCHELL et al., 2019). São úteis para transparência técnica, mas não substituem obrigações normativas nem a documentação do sistema completo. O modelo é apenas um componente.
Contratar transfere execução, não responsabilidade institucional. Antes de uma prova de conceito, pergunte:
A Resolução CNJ nº 615/2025 prioriza interoperabilidade, flexibilidade de adaptação e não dependência tecnológica. Cláusulas, arquitetura e documentação devem permitir continuidade, auditoria autorizada, substituição de componentes e encerramento seguro.
Sistemas de ML acumulam dívida técnica em dados, dependências, configurações, interfaces, consumidores e ciclos de retroalimentação. Sculley et al. (2015) mostram que o código do modelo representa pequena parte do sistema e que mudanças podem gerar efeitos distantes. Por isso, o Canvas precisa prever manutenção, versões e proprietário de cada dependência - não apenas a entrega inicial.
O Canvas abaixo é editável em Markdown. Preencha com frases curtas e verificáveis. Use “a definir” acompanhado de responsável e prazo quando ainda não houver evidência. Não preencha lacunas por suposição. A cada mudança de finalidade, população, integração, dados ou ação, crie nova versão.
| Bloco | Campo | Preenchimento |
|---|---|---|
| identificação | nome, unidade, responsável e versão | |
| problema | processo atual, evidência, período, volume e consequência | |
| escopo | resultado desejado e o que fica fora | |
| atores | usuários, pessoas afetadas, participação e canais alternativos | |
| alternativas | mudança de processo, formulário, integração, regra e opção sem ML | |
| linha de base | indicadores atuais e solução simples de comparação | |
| tarefa | entrada, saída, momento, ação permitida e uso proibido | |
| supervisão | decisão humana, fonte para revisão, abstenção e correção | |
| dados | origem, período, finalidade, hipótese jurídica, sigilo e rótulos | |
| qualidade | cobertura, ausências, representatividade e documentação | |
| sucesso | métricas técnicas, operacionais, jurídicas, humanas e distributivas | |
| erro e parada | erro grave, reversibilidade, não implantação e suspensão | |
| implantação | offline, sombra, piloto, comunicação, suporte e rollback | |
| governança inicial | equipe, documentos, segurança, cadastro e análise de risco pendente | |
| continuidade | monitoramento, portabilidade, custos, dependências e descontinuidade |
Leia-o em três direções:
Procure frases vagas como “melhorar eficiência”, “dados do tribunal”, “revisão humana” ou “alta acurácia”. Substitua-as por processo, população, fonte, responsável, comparação e consequência. O Canvas concluído é uma hipótese estruturada, não uma promessa de resultado.
Este caso é inteiramente sintético e serve apenas para aprendizagem.
| Campo | Exemplo parcialmente preenchido |
|---|---|
| problema | Triagem manual de cinco tipos documentais gera retrabalho; medição do período e por classe ainda necessária. |
| resultado desejado | Reduzir tempo e retrabalho sem aumentar encaminhamento incorreto. |
| fora do escopo | Decidir mérito, urgência, autenticidade ou efeito jurídico do documento. |
| atores | Servidores de triagem, equipe técnica, gestores, advocacia e partes; formas de participação a definir. |
| alternativas | Revisar formulário e metadados; criar regras para padrões claros; manter processo manual como referência. |
| tarefa | Classificação multiclasse com abstenção. |
| entrada | Texto e layout autorizados; registrar se houve OCR. |
| saída | Classe sugerida, probabilidade estimada e trecho indicativo. |
| ação humana | Servidor confirma ou corrige antes de roteamento; modo manual permanece disponível. |
| dados | Separação por processo e tempo; revisão de rótulos; finalidade, hipótese jurídica, sigilo, retenção e cobertura a validar. |
| linha de base | Desempenho e tempo do processo manual e de regras simples. |
| sucesso | Macro-F1, sensibilidade por classe, calibração, abstenção, correção, tempo, retrabalho e distribuição dos erros. Limites numéricos a definir após a linha de base. |
| risco preliminar | A classificação de apoio supervisionada pode aproximar-se de BR1; finalidade, contexto e integração serão analisados no Capítulo 6. |
| implantação | Offline → sombra → piloto em uma unidade → decisão documentada. |
| não implantar se | Base jurídica ausente; revisão inviável; desempenho crítico inferior à linha de base; barreira de acesso; segurança insuficiente; ganho irrelevante. |
O exemplo deixa lacunas deliberadas. Inventar um percentual, uma base jurídica ou uma representatividade não torna o projeto completo; apenas encobre o trabalho necessário.
Transformar um cenário do Judiciário em proposta inicial que demonstre alinhamento entre problema, atores, alternativa, tarefa, dados, sucesso e implantação.
Escolha um cenário: classificação de peças; extração de campos; agrupamento de documentos semelhantes; previsão de volume; pesquisa jurisprudencial; ou sumarização para apoio interno. Use somente situação profissional genérica ou dados inteiramente sintéticos.
Canvas preenchido, com lacunas identificadas; síntese do projeto; e decisão fundamentada entre prosseguir para análise de risco, reformular o problema ou adotar alternativa sem ML.
Um bom produto não precisa recomendar ML. Ele explicita evidências, alternativas e pendências; preserva opção manual; mede o fluxo, não só o modelo; e estabelece critérios capazes de interromper o projeto. Se problema, tarefa, dados e métricas não formarem uma cadeia coerente, retorne ao primeiro bloco em vez de acrescentar tecnologia.
Uma equipe escreve: “Implantar um grande modelo de linguagem para acelerar a unidade”. Reescreva o ponto de partida e explique qual confusão foi cometida.
Em uma classificação assistida, apenas servidores usam a interface. Isso permite concluir que são as únicas pessoas relevantes ao projeto? Justifique.
Um modelo atingiu macro-F1 de 0,88. Por que esse dado não demonstra, sozinho, que deve ser implantado?
Defina uma condição de abstenção e duas condições para que a revisão humana seja efetiva.
Qual diferença central existe entre teste offline, modo sombra e piloto?
Cite quatro evidências ou condições que reduzam dependência de fornecedor e permitam continuidade ou saída segura.
O ponto de partida deve descrever processo, evidência, população, consequência e resultado desejado, por exemplo: “A unidade medirá o tempo e o retrabalho na localização de informações para verificar se há gargalo e se uma intervenção pode reduzi-lo sem aumentar erro relevante”. A redação original confunde solução tecnológica com problema institucional. Revise a Seção 5.1.
Não. Usuários operam o sistema, enquanto pessoas afetadas podem sofrer demora, encaminhamento ou correção sem ver a interface. Equipe técnica, gestores, advocacia, partes e órgãos de controle podem ter papéis distintos. Revise as Seções 5.3 e 5.4.
Faltam desempenho por classe, erro relevante, calibração, linha de base humana e simples, impacto no tempo e retrabalho, acessibilidade, distribuição de efeitos, custos e requisitos jurídicos e de segurança. Métrica de modelo não comprova benefício do sistema. Revise as Seções 5.5, 5.8 e 5.9.
O sistema pode abster-se quando a probabilidade estimada não supera o limiar validado, o formato está fora do escopo ou há múltiplos tipos. A revisão exige, entre outras condições, acesso à fonte e ao contexto, tempo, competência, autoridade para discordar, registro e caminho de correção. Revise a Seção 5.7.
Teste offline compara saídas sem integração ao fluxo; modo sombra processa entradas do ambiente, mas não influencia o trabalho; piloto introduz uso real em população e período limitados, com suporte, critérios e rollback. Revise a Seção 5.10.
Logs exportáveis; formatos documentados para dados e configurações; teste local independente; comunicação e recusa de mudança de versão; cláusulas de eliminação; documentação de componentes e subcontratados; interoperabilidade; modo manual; plano de transição; e custos de saída conhecidos. Revise a Seção 5.12.
Neste capítulo, começamos pelo problema, não pela tecnologia. Separamos dificuldade institucional, tarefa computacional e solução sociotécnica; usamos evidência e teoria de mudança para tornar explícito como uma saída poderia produzir valor público.
Distinguimos usuários de pessoas afetadas e incluímos acessibilidade e canais alternativos desde o escopo. Comparamos alternativas sem ML e linha de base, documentamos finalidade e condições dos dados e definimos entrada, saída, abstenção, ação humana e usos proibidos. O sucesso passou a reunir indicadores técnicos, operacionais, jurídicos, humanos, distributivos e institucionais.
Também estabelecemos erro relevante e condição de não implantação. Teste offline, modo sombra e piloto foram tratados como fases que produzem evidências para novas decisões, com rollback e possibilidade real de encerramento. Equipe interdisciplinar, documentação, portabilidade e manutenção completam o sistema que existe ao redor do modelo.
O Canvas consolidou essas relações e tornou visíveis as pendências. No próximo capítulo, retomaremos o mesmo projeto para classificar preliminarmente seus riscos e desenhar governança, proteção de dados, segurança, transparência, supervisão, contestação, resposta a incidentes, monitoramento e descontinuidade. Um projeto tecnicamente plausível ainda precisa demonstrar que pode ser usado de modo responsável.
Os termos Canvas de projeto, cartão do modelo, dívida técnica, linha de base, modo sombra, MVP, pessoa afetada, piloto, rollback, solução sociotécnica e teoria de mudança foram selecionados para o glossário cumulativo.
BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD). Brasília, DF: Presidência da República, 2018. Disponível em: texto compilado da LGPD. Acesso em: 13 ago. 2026.
CONSELHO NACIONAL DE JUSTIÇA (CNJ). Resolução nº 615, de 11 de março de 2025. Estabelece diretrizes para o desenvolvimento, utilização e governança de soluções desenvolvidas com recursos de inteligência artificial no Poder Judiciário. Brasília, DF: CNJ, 2025. Disponível em: Atos CNJ. Acesso em: 13 ago. 2026.
GEBRU, Timnit et al. Datasheets for datasets. Communications of the ACM, v. 64, n. 12, p. 86–92, 2021. DOI: 10.1145/3458723.
MITCHELL, Margaret et al. Model cards for model reporting. In: Proceedings of the Conference on Fairness, Accountability, and Transparency. New York: ACM, 2019. p. 220–229. DOI: 10.1145/3287560.3287596.
SCULLEY, D. et al. Hidden technical debt in machine learning systems. In: Advances in Neural Information Processing Systems, v. 28, 2015. p. 2503–2511. Disponível em: Google Research. Acesso em: 13 ago. 2026.
Descrição acessível: o texto é apresentado em HTML semântico, com títulos, tabelas e alternativas textuais. Os laboratórios interativos são complementos e não substituem a leitura.