Quando as obrigacoes do fornecedor se aplicam e o que fazer a seguir

As obrigacoes do fornecedor aplicam-se quando uma empresa SaaS e responsavel por um sistema de IA ou modelo de IA de proposito geral ao abrigo do EU AI Act. A questao nao e apenas quem escreveu o codigo do modelo. Tambem importa se a empresa desenvolve, manda desenvolver, oferece sob o seu nome, coloca no mercado da UE, modifica substancialmente um sistema de alto risco, altera a finalidade prevista ou fornece um modelo GPAI.

O proximo passo e operacional: abrir um registo de obrigacoes do fornecedor, documentar o ativo de IA, finalidade prevista, papel, trilho de risco, obrigacoes acionadas, owner de evidencias e gate de lancamento.

Porque isto importa

Estas obrigacoes definem quem deve provar que o sistema foi desenhado, documentado, avaliado, monitorizado e suportado. Para sistemas de alto risco, o artigo 16 inclui sistema de qualidade, documentacao tecnica, logs, avaliacao de conformidade, declaracao UE de conformidade, marcacao CE quando aplicavel, registo, acoes corretivas e cooperacao com autoridades.

Em SaaS, a pergunta aparece no trabalho normal de produto: scoring por IA, modelo de terceiro integrado, modulo com marca propria, mudanca de finalidade ou API para modelo afinado.

Quando se aplica

Comece pelos papeis. A mesma empresa pode ser deployer de uma ferramenta interna, fornecedora de uma funcionalidade para clientes, distribuidora de uma ferramenta embutida e fornecedora GPAI de uma API. Dizer "usamos IA de vendor" nao chega.

Triggers comuns incluem funcionalidades de IA para clientes, modulos white-label, ranking ou scoring, recomendacoes automatizadas, contextos de alto risco, novos modelos, novas fontes de dados, novos segmentos de clientes e novas promessas de produto.

O que documentar primeiro

O registo minimo responde a seis perguntas: qual e o ativo de IA, qual e a finalidade, qual e o papel da empresa, que trilho de obrigacoes se aplica, que evidencias sao necessarias e quando reavaliar.

Inclua documentacao tecnica, registos de risco, governanca de dados, testes, decisoes de logging, human oversight, instrucoes para clientes, documentos de vendors, monitorizacao e aprovacoes de release.

Integrar no delivery

O workflow deve viver em product discovery, architecture review, vendor review, release readiness e monitorizacao pos-lancamento. Product descreve o caso de uso. Engineering fornece factos tecnicos. Legal ou compliance interpreta papeis e obrigacoes. Security valida controlos. Equipas de cliente usam explicacoes aprovadas.

Erros comuns

O primeiro erro e assumir que o vendor do modelo e sempre o fornecedor do sistema. Outros erros sao inventarios de IA sem campos de papel, respostas juridicas pontuais, informacao downstream perdida para clientes e evidencias separadas do release.

FAQ

Qual e o objetivo pratico?

Identificar quem e responsavel pelo sistema de IA ou modelo GPAI e ligar esse papel a documentacao, controlos de risco, informacao para clientes, monitorizacao e evidencias.

Quando se aplica a SaaS?

Quando a equipa desenvolve, manda desenvolver, oferece sob o seu nome, coloca no mercado, modifica substancialmente, muda a finalidade ou fornece um modelo GPAI.

Por onde comecar?

Por um registo que cubra ativo, finalidade, papel, trilho de risco, obrigacoes, owner de evidencias, local da documentacao, gate de lancamento e triggers de reavaliacao.