Quando modelos de IA de proposito geral se aplicam e o que fazer depois

Modelos de IA de proposito geral se aplicam a uma equipe SaaS quando a empresa fornece, integra, implanta, fine-tunea, configura ou depende materialmente de um modelo capaz de executar muitos tipos de tarefas. A primeira pergunta nao e se a empresa e um laboratorio. E onde os modelos aparecem em produto, fornecedores, workflows internos, compromissos com clientes e evidencias.

No AI Act, as obrigacoes principais ficam no capitulo V. O artigo 53 exige documentacao tecnica, informacao para provedores downstream, politica de copyright e resumo publico do treinamento. O artigo 55 adiciona obrigacoes para modelos com risco sistemico. O artigo 51 explica a classificacao.

Quando se aplica na pratica

Aplica-se quando produto ou processo depende de um modelo geral: API, copilot, resumo de documentos, recomendacoes, classificacao, respostas de suporte, busca, geracao de texto ou codigo, ou workflows configuraveis por clientes.

Tambem se aplica internamente. Suporte, vendas, seguranca ou operacoes podem usar IA de forma que cria perguntas de privacidade, seguranca, copyright, confianca do cliente e mapeamento de papeis.

Quando pode nao ser o tema principal

Em uso interno de baixo risco, o tema principal pode ser uso aceitavel, confidencialidade e seguranca. Mas uma conclusao "nao se aplica" deve ser documentada. Um pequeno piloto pode virar dependencia de produto.

Passo 1: inventario de modelos

Liste APIs hospedadas, open source, fine-tuning, recursos vendor, ferramentas internas, copilots, assistentes de suporte, analytics e workflows configuraveis por clientes.

Para cada item, registre modelo, fornecedor, versao, hospedagem, caso de uso, dono, dados, exposicao a clientes, outputs importantes, fine-tuning, configuracao cliente e documentacao do fornecedor.

Passo 2: mapa de papeis

Determine se a empresa e provedora do modelo, provedora downstream de sistema de IA, deployer, usuaria de recurso vendor ou modificadora do modelo. O papel orienta obrigacoes e evidencias.

O mapa deve estar em product intake, vendor review, security, privacy, architecture, launch readiness e customer trust.

Passo 3: evidencia do fornecedor

Se ha modelo externo, colete evidencia cedo. Peca capacidades, limites, usos permitidos, versoes, avisos de mudanca, seguranca, avaliacao, retencao, uso de dados para treinamento, copyright, resumo de treinamento e incidentes.

Se o fornecedor menciona risco sistemico, pergunte que evidencias do artigo 55 estao disponiveis e que mudancas exigem notificacao.

Passo 4: caminho de revisao

Nem todo uso precisa da mesma revisao. Leve para produtividade interna aprovada. Padrao para recursos vendor, copilots, suporte, analytics ou outputs visiveis ao cliente. Reforcada para dados sensiveis, clientes regulados, fine-tuning, dependencia critica ou configuracao por clientes.

Cada revisao deve terminar em approved, approved with conditions, blocked ou more facts needed. Condicoes precisam de dono e data.

Passo 5: gatilhos de mudanca

Decisoes envelhecem rapido. Novo fornecedor, versao, feature, dados, cliente regulado, fine-tuning, hosting, politica vendor, incidente ou mudanca relevante de comportamento devem reabrir a revisao.

FAQ

Para que serve essa governanca?

Para saber onde modelos afetam a empresa, qual papel ela tem, que evidencia existe, quais controles aplicam e quando revisar de novo.

Quando se aplica a SaaS?

Quando a equipe fornece, integra, implanta, configura, fine-tunea ou depende de um modelo em produto, workflow, fornecedor, promessa comercial ou review enterprise.

O que documentar primeiro?

Inventario de modelos e mapa de papeis. Depois evidencia do fornecedor, versao, caso de uso, dados, clientes, seguranca, privacidade, copyright, limites, monitoramento, mudancas e respostas aprovadas.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 51, Article 53, Article 55, Article 56 and Article 113.