Praticas de IA proibidas: guia pratico para equipas SaaS

As praticas de IA proibidas sao usos de IA que uma equipa SaaS deve bloquear antes de chegarem a clientes, colaboradores, workflows de vendors ou processos internos. O Article 5 do EU AI Act cobre um conjunto limitado de praticas consideradas inaceitaveis, incluindo manipulacao nociva, exploracao de vulnerabilidades, certas formas de social scoring, alguns usos de previsao de risco criminal, scraping nao direcionado de imagens faciais, reconhecimento de emocoes no trabalho e na educacao, categorizacao biometrica sensivel e identificacao biometrica remota em tempo real em espacos publicos para law enforcement, salvo excecoes estreitas.

A resposta pratica e nao esperar que legal reveja uma funcionalidade acabada. A equipa deve ter um screen pre-lancamento que pergunte se o caso de uso de IA pode cair numa categoria proibida, bloqueie casos claros, escale casos incertos e guarde evidencia da decisao. O screen deve cobrir funcionalidades de produto, ferramentas internas, sistemas de vendors embutidos, integracoes de modelos e automatizacoes configuraveis pelo cliente.

Porque importa

O screening de praticas proibidas e a porta de entrada da AI governance. Se um use case e proibido, a equipa nao deve construir controlos normais em redor dele. A resposta correta e parar, redesenhar, limitar ou escalar antes de o trabalho ficar preso no roadmap ou num compromisso com cliente.

Em SaaS, a IA entra muitas vezes de forma discreta: nudges de produto, account scoring, HR analytics, ferramentas de vendors ou modulos biometricos em plataformas ja usadas. Uma pequena alteracao num ticket pode mudar a posicao regulatoria e etica do servico.

O que verificar

Traduza o Article 5 em perguntas operacionais. O sistema usa tecnicas escondidas, manipulativas ou enganosas que podem alterar decisoes e causar dano significativo? Explora vulnerabilidades associadas a idade, deficiencia ou situacao social ou economica? Avalia pessoas entre contextos? Faz social scoring, previsao criminal baseada apenas em profiling, bases de reconhecimento facial por scraping, reconhecimento de emocoes em trabalho ou educacao, inferencia biometrica sensivel ou identificacao biometrica remota?

O nome do modelo nao chega. E preciso olhar para finalidade, contexto, dados, pessoas afetadas e efeito do output.

Workflow pratico

Adicione perguntas de IA ao product review, vendor review, security review, privacy review e aprovacao de ferramentas internas. Nao pergunte apenas se algo e proibido. Pergunte o que o sistema faz, quem afeta, que dados usa, se influencia decisoes, se processa biometria, se infere emocoes e se toca trabalho, educacao, credito, servicos essenciais, law enforcement ou seguranca publica.

Respostas "nao" claras podem seguir para classificacao de IA e risk review normais. Respostas "sim" claras devem parar ate legal e compliance aprovarem um redesign ou confirmarem que o caso esta fora da proibicao. Respostas incertas vao para um reviewer nomeado.

A decisao deve registar sistema, owner, vendor, finalidade, pessoas afetadas, dados, geografia, papel no AI Act, perguntas Article 5, conclusao, fundamento, alteracoes exigidas, aprovador e trigger de nova review.

Evidencia a guardar

Guarde o intake, descricao de produto ou vendor, nota de data flow, analise de pessoas afetadas, screenshots ou configuracao, decisao, fundamento, reviewer, data e acoes de redesign. Com vendor, guarde documentacao de IA, compromissos contratuais e respostas sobre biometria, emotion recognition, profiling, treino de modelos e manipulacao de utilizadores.

A evidencia deve tambem mostrar quando a decisao sera reaberta: nova finalidade, novo grupo de utilizadores, novo mercado, novas fontes de dados, mudanca de human review, configuracao pelo cliente ou nova guidance.

Erros comuns

O primeiro erro e rever demasiado tarde. Quando uma funcionalidade esta quase pronta, design, contrato, messaging e engineering podem ja depender de uma premissa errada. O segundo e rever apenas funcionalidades customer-facing. Ferramentas internas tambem podem criar risco quando afetam trabalhadores, candidatos, formacao, produtividade, fraude, suporte ou security.

Nao confie em labels de vendor como insight, sentiment, safety ou personalization. A pergunta real e o que o sistema faz e como afeta pessoas. Human in the loop pode ajudar, mas nao corrige automaticamente manipulacao proibida ou inferencia biometrica sensivel.

FAQ

Qual e o objetivo pratico?

Identificar usos de IA que devem ser bloqueados, redesenhados ou escalados antes de entrarem em produto, workflow de vendor ou processo interno.

Quando se aplica a SaaS?

Quando a equipa constroi, compra, integra, vende, configura ou usa IA que pode tocar uma categoria do Article 5.

O que documentar primeiro?

Um intake, decision record, reviewer nomeado e launch gate ligado a produto, vendor, privacy, security e customer trust.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.