Um sistema de IA governa-se desde a primeira ideia até ao dia em que é desligado, e não apenas enquanto está em produção. A gestão do ciclo de vida da IA é exatamente isso: saber, em cada fase, quem decide, com que provas e o que fica conservado. O Regulamento da IA associa deveres concretos a quase todas as fases. Neste artigo: as fases, as obrigações de cada uma, os pontos de decisão, o controlo de alterações e a desativação.
O essencial
- A gestão do ciclo de vida da IA é uma disciplina de governação: decide quem faz avançar um sistema, com que provas e o que se conserva. O MLOps automatiza o pipeline, mas não decide.
- O Regulamento da IA só usa «ciclo de vida» 11 vezes, mas quase todas as obrigações de risco elevado se prendem a uma fase.
- Uma modificação substancial reabre a avaliação da conformidade e pode transformar o responsável pela implantação em prestador.
- Desde o Omnibus Digital, os sistemas de risco elevado já no mercado só ficam abrangidos após alterações significativas da conceção.
- A desativação, fase que ninguém planeia, concentra a retirada, o estatuto na base de dados da UE e a conservação documental de 10 anos.
Gestão do ciclo de vida da IA: o que significa e o que o MLOps deixa de fora
Entendemos por gestão do ciclo de vida da IA a governação de um sistema de IA através de todas as suas fases: quem responde por ele, quem decide o quê, com que provas, como se controlam as alterações e como se encerra. As páginas que dominam a pesquisa (IBM, AWS, o guia da GSA norte-americana e vários fornecedores de MLOps, CRM e segurança) descrevem o ciclo de vida da IA como um pipeline de engenharia: definição do problema, dados, treino, avaliação, implantação, monitorização. Revimos as dez páginas legíveis mais bem posicionadas: nenhuma cita as normas ISO/IEC 42001, 5338 ou 22989, nem a OCDE, nenhuma refere a comunicação de incidentes graves, uma única cita um artigo do Regulamento da IA e apenas duas falam de desativação.
A diferença é de natureza. O MLOps automatiza o pipeline: versiona dados e modelos, corre testes, publica e reverte. A gestão do ciclo de vida da IA decide: aprova a passagem à fase seguinte, recusa-a ou impõe condições, e guarda a prova. Um pipeline impecável pode pôr em produção um sistema que nunca devia ter saído da conceção. Por isso tratamos o tema ao lado da gestão do risco de modelos e da gestão de riscos de IA, não como questão de ferramentas.
O Regulamento (UE) 2024/1689 usa a palavra com parcimónia. Na nossa contagem sobre o texto do Jornal Oficial, «ciclo de vida» surge 11 vezes: 7 nos considerandos e 4 no articulado e nos anexos (artigos 9.º, n.º 2, 15.º, n.º 1, e 40.º, n.º 2, e anexo IV, ponto 6). O artigo 9.º descreve a gestão de riscos como «um processo iterativo contínuo, planeado e executado ao longo de todo o ciclo de vida» de um sistema de risco elevado, com revisão e atualização sistemáticas. O artigo 15.º pede desempenho coerente ao longo desse ciclo e o anexo IV, ponto 6, a descrição das alterações relevantes feitas pelo prestador; noutros termos, o artigo 12.º, n.º 1, pede registos durante a vida útil e o artigo 72.º, n.º 2, dados pós-comercialização durante todo o tempo de vida. Conta menos a palavra do que a estrutura (ver o nosso guia operacional do Regulamento da IA).
As fases do ciclo de vida da IA: quatro modelos de referência comparados
Há quatro referências sérias para dividir o ciclo de vida da IA em fases. Alinhámo-las com o nosso modelo de trabalho em oito fases; a coluna da ISO/IEC 22989 é a retomada pela Autoridade Europeia para a Proteção de Dados (AEPD) nas suas orientações de 11 de novembro de 2025.
| Fase (modelo de trabalho) | ISO/IEC 22989 / AEPD | NIST AI RMF | OCDE | ISO/IEC 42001, anexo A.6.2 |
|---|---|---|---|---|
| Iniciação e finalidade prevista | Início e análise | Plan and Design | Conceção, dados e modelos | Requisitos e especificação (A.6.2.2) |
| Aquisição e preparação de dados | Aquisição e preparação de dados | Collect and Process Data | Conceção, dados e modelos | (os controlos de dados estão no A.7) |
| Conceção e desenvolvimento | Desenvolvimento | Build and Use Model | Conceção, dados e modelos | Documentação de conceção e desenvolvimento (A.6.2.3) |
| Verificação e validação | Verificação e validação | Verify and Validate | Verificação e validação | Verificação e validação (A.6.2.4) |
| Implantação | Implantação | Deploy and Use | Implantação | Implantação (A.6.2.5) |
| Operação e monitorização | Operação e monitorização; validação contínua | Operate and Monitor | Operação e monitorização | Operação e monitorização (A.6.2.6); registos de eventos (A.6.2.8) |
| Reavaliação e alteração | Reavaliação | (TEVV ao longo de todo o ciclo) | (iterativo, não sequencial) | Documentação técnica mantida atualizada (A.6.2.7) |
| Desativação | Desativação | (não é uma fase autónoma) | Decidida durante a operação e monitorização | (sem controlo dedicado) |
A ISO/IEC 22989 dá o vocabulário; a ISO/IEC 5338:2023, publicada em dezembro de 2023 pelo JTC 1/SC 42, transforma as fases em processos. Assenta nas normas ISO/IEC/IEEE 15288 e 12207, acrescenta-lhes processos próprios da IA retirados da ISO/IEC 22989 e da ISO/IEC 23053, e aplica-se quer a organização desenvolva o sistema, quer o adquira. A figura do NIST AI RMF é adaptada do quadro de classificação da OCDE, o que explica a proximidade das duas colunas. A ISO/IEC 42001 distribui pelos mesmos momentos os controlos do anexo A.6.2, como mostramos na análise da pilha de normas do AI Act. A nossa recomendação: escolha um modelo de trabalho, mapeie os outros para ele e nunca mantenha três em paralelo. Três vocabulários produzem três registos de evidências impossíveis de reconciliar numa auditoria.
O ciclo de vida da IA no Regulamento da IA: obrigações fase a fase
Eis, fase a fase, o que o Regulamento da IA exige aos sistemas de risco elevado e as provas que uma autoridade vai pedir.
| Fase | O que o Regulamento da IA exige | Artigos | Provas a conservar |
|---|---|---|---|
| Iniciação e finalidade prevista | Definir a finalidade prevista, classificar, abrir o sistema de gestão de riscos | Art. 3.º, ponto 12; art. 6.º; art. 9.º, n.os 1 e 2 | Declaração da finalidade, nota de classificação, registo de riscos aberto |
| Aquisição e preparação de dados | Governação dos dados de treino, validação e teste | Art. 10.º; anexo IV, ponto 2, alínea d) | Fichas de dados, proveniência, análise de enviesamentos |
| Conceção e desenvolvimento | Documentação técnica antes da colocação no mercado; transparência e instruções; supervisão humana desde a conceção; exatidão, solidez e cibersegurança | Arts. 11.º, 13.º, 14.º e 15.º; art. 17.º, n.º 1, alíneas b) e c) | Dossiê do anexo IV, instruções de utilização, desenho da supervisão |
| Verificação e validação | Testes prévios com métricas definidas; avaliação da conformidade, declaração, marcação CE | Art. 9.º, n.os 6 a 8; art. 17.º, n.º 1, alínea d); arts. 43.º, 47.º e 48.º | Relatórios de teste, processo de conformidade, declaração UE de conformidade |
| Implantação | Registo prévio na base de dados da UE (anexo III); deveres do responsável pela implantação; avaliação de impacto sobre direitos fundamentais, em certos casos | Arts. 49.º, 26.º e 27.º | Comprovativo de registo, lista de verificação, avaliação de impacto quando devida |
| Operação e monitorização | Registos durante a vida útil; acompanhamento pós-comercialização; vigilância e suspensão pelo responsável pela implantação; incidentes graves | Arts. 12.º e 19.º; art. 26.º, n.os 5 e 6; arts. 72.º e 73.º | Conservação dos registos, plano e relatórios de acompanhamento, registo de incidentes |
| Alteração | Modificação substancial obriga a nova avaliação, salvo alterações predeterminadas no anexo IV, ponto 2, alínea f); quem modifica substancialmente passa a prestador | Art. 3.º, ponto 23; art. 43.º, n.º 4; art. 25.º, n.º 1; anexo IV, ponto 6 | Registo de alterações com decisão de triagem, documentação atualizada |
| Desativação | Medidas corretivas, retirada, desativação ou recolha; documentação conservada 10 anos; estatuto atualizado na base de dados | Arts. 20.º e 18.º; anexo VIII, secção A, ponto 7 | Registo de desativação, calendário de conservação, prova de eliminação |
O Regulamento (UE) 2026/1744, o Omnibus Digital sobre a IA, adiou as obrigações de risco elevado do anexo III para 2 de dezembro de 2027 e as do anexo I (produtos) para 2 de agosto de 2028. Integrou o plano de acompanhamento pós-comercialização na documentação técnica do anexo IV, pediu à Comissão orientações com um modelo até 2 de setembro de 2027 (novo artigo 72.º, n.º 3) e tornou o sistema de gestão da qualidade proporcional à dimensão das PME e das pequenas empresas de média capitalização (artigo 17.º, n.º 2). O adiamento não altera a lógica do ciclo de vida da IA: as provas da primeira linha têm de existir antes das da última.
Pontos de decisão no ciclo de vida da IA: quem decide e com que provas
Um ponto de decisão é o momento em que alguém com mandato aprova, recusa ou condiciona a passagem à fase seguinte, com base em provas fixadas de antemão. Propomos seis.
- <b>Entrada.</b> O sistema entra no inventário de sistemas de IA com um responsável identificado e uma finalidade prevista escrita. Sem estes dois elementos há apenas uma experiência sem dono.
- <b>Aprovação da conceção.</b> Classificação, avaliação de impacto e registo de riscos estão feitos. O comité de governação da IA decide avançar ou parar e regista a fundamentação.
- <b>Passagem a produção.</b> A validação cumpriu as métricas fixadas antes dos testes, a documentação está completa e a supervisão humana tem titulares nomeados. Nos sistemas de risco elevado, a avaliação da conformidade e o registo na base de dados da UE estão concluídos.
- <b>Triagem de alterações.</b> Cada alteração de modelo, de dados ou de finalidade é registada e classificada como rotineira, predeterminada ou substancial. A classificação é uma decisão, com autor e data, e não um campo preenchido por omissão.
- <b>Reavaliação periódica.</b> Pelo menos uma vez por ano e depois de qualquer incidente, comparam-se os resultados reais com os riscos identificados. Se divergirem, o sistema volta ao segundo ponto.
- <b>Desativação.</b> Decisão, notificação, arquivo e eliminação, por esta ordem. É um ponto de decisão de pleno direito, com as mesmas exigências de prova.
Quanto aos papéis, o responsável de negócio é dono da finalidade; o comité decide nos pontos de aprovação, produção e desativação; o jurídico e o encarregado da proteção de dados validam a classificação e a base de licitude; a validação de modelos, como segunda linha, testa e pode bloquear; a segurança verifica acessos e cibersegurança. Uma model card atualizada em cada ponto torna o ciclo de vida da IA legível para quem chega depois. Na AI Sigil, os processos são modelados como fases, cada uma com os seus formulários e aprovações, no registo de sistemas de IA.
Controlo de alterações: quando uma atualização passa a modificação substancial
A alteração é o momento em que o ciclo de vida da IA se torna direito. O artigo 3.º, ponto 23, define a modificação substancial como uma alteração posterior à colocação no mercado ou em serviço, não prevista nem planeada na avaliação da conformidade inicial, que afeta a conformidade com os requisitos do capítulo III, secção 2, ou modifica a finalidade prevista. O artigo 43.º, n.º 4, tira a consequência: nova avaliação da conformidade, quer o sistema modificado se destine a ser distribuído, quer continue a ser utilizado pelo atual responsável pela implantação. Para os sistemas que continuam a aprender, as alterações predeterminadas na avaliação inicial e descritas no anexo IV, ponto 2, alínea f), não constituem modificação substancial. O artigo 25.º, n.º 1, alíneas b) e c), junta-lhe a mudança de papel: quem introduz a modificação passa a ser prestador.
Na redação que o Omnibus deu ao artigo 111.º, n.º 2, um sistema de risco elevado já no mercado antes da data de aplicação do capítulo III só fica abrangido se, a partir dessa data, sofrer alterações significativas na sua conceção. Um considerando esclarece que «alteração significativa» equivale, em substância, a modificação substancial. O registo de alterações torna-se assim o gatilho que puxa os sistemas antigos para o âmbito.
Faltam as orientações. A Comissão publicou a 19 de maio de 2026 um projeto de orientações sobre a classificação de risco elevado, com consulta prorrogada até 23 de julho e versão final prevista até ao fim de 2026, e inclui a modificação substancial entre as orientações que o Serviço para a IA ainda prepara. O documento do CERRE de junho de 2026 defende que as alterações rotineiras fiquem, em regra, fora do regime, em coerência com a exceção do artigo 43.º, n.º 4, e dá o exemplo do fornecedor que troca o modelo de IA de finalidade geral subjacente por uma versão mais recente. Fora da UE, a orientação final da FDA de 4 de dezembro de 2024 sobre planos de controlo de alterações predeterminadas divide o plano em três partes: descrição das modificações, protocolo de modificação e avaliação de impacto. Serve de molde ao plano do anexo IV, ponto 2, alínea f).
Perguntas de triagem
- A alteração muda a finalidade prevista?
- Afeta um requisito do capítulo III (exatidão, solidez, supervisão humana, dados)?
- Estava predeterminada na documentação técnica?
- Quem a fez: prestador, responsável pela implantação ou fornecedor a montante?
- Atinge um sistema antigo depois da data de aplicação?
Operação e monitorização: registos, deriva e incidentes
A operação é a fase mais longa do ciclo de vida da IA e, paradoxalmente, a menos documentada. O artigo 72.º, n.os 1 e 2, obriga o prestador a manter um sistema de acompanhamento pós-comercialização que recolha e analise dados sobre o desempenho durante todo o tempo de vida do sistema. Do lado do responsável pela implantação, o artigo 26.º, n.º 5, impõe a vigilância com base nas instruções de utilização, a informação do prestador e a suspensão da utilização quando surgir um risco. A supervisão humana desenhada na conceção só vale se alguém a exercer aqui.
Os registos gerados automaticamente (artigo 12.º) devem ser conservados pelo menos seis meses, tanto pelo prestador (artigo 19.º, n.º 1) como pelo responsável pela implantação (artigo 26.º, n.º 6), salvo disposição em contrário do direito da União ou nacional. Seis meses são um mínimo, não uma política: o calendário de conservação decide-se na conceção.
A comunicação de incidentes graves segue o artigo 73.º: imediatamente e, o mais tardar, 15 dias após o conhecimento; 2 dias em caso de infração generalizada ou de incidente grave na aceção do artigo 3.º, ponto 49, alínea b), que abrange as infraestruturas críticas; 10 dias em caso de morte. É admitido um relatório inicial incompleto (artigo 73.º, n.º 5). A Comissão já publicou um modelo para estas comunicações; integre-o desde já no registo de incidentes.
Resta a deriva. Um modelo que cumpre as métricas no dia da passagem a produção pode afastar-se delas em semanas, porque mudaram os dados de entrada ou o comportamento dos utilizadores. A deriva do modelo é o sinal operacional que deve alimentar o ponto de reavaliação. A AEPD reconhece-o ao autonomizar a «validação contínua» como fase própria para os sistemas que continuam a aprender.
Desativação: a fase que ninguém planeia
As referências tratam mal o fim de vida. Nas orientações da AEPD de 11 de novembro de 2025, a lista de riscos por fase (anexo 3) não associa nenhum risco à implantação nem à desativação, sobre a qual diz apenas que o sistema deve ser desmantelado de forma responsável e eficiente. A OCDE não tem uma fase autónoma de desativação: a decisão pode surgir durante a operação e monitorização. E, na nossa análise, só duas das dez páginas mais bem posicionadas sobre o ciclo de vida da IA mencionam o tema.
Mas é aqui que aterram várias obrigações. O artigo 20.º impõe ao prestador que retire, desative ou recolha um sistema que deixou de estar conforme e que informe distribuidores e responsáveis pela implantação. O artigo 18.º obriga a conservar a documentação técnica, a documentação do sistema de gestão da qualidade e a declaração UE de conformidade durante 10 anos após a colocação no mercado. O anexo VIII, secção A, ponto 7, prevê a atualização do estatuto na base de dados da UE (deixou de estar no mercado ou em serviço, recolhido). E os registos, os dados de treino e os dados de inferência continuam sujeitos à limitação da conservação e ao direito ao apagamento, como explicamos em RGPD e inteligência artificial.
Lista de verificação para encerrar o ciclo de vida da IA:
- Decisão e motivo registados, com o autor da decisão.
- Responsáveis pela implantação e utilizadores informados com antecedência.
- Acessos revogados e artefactos do modelo arquivados ou eliminados.
- Dados pessoais eliminados ou anonimizados segundo o calendário de conservação.
- Documentação arquivada durante todo o período de conservação.
- Inventário e estatuto na base de dados da UE atualizados, com o sistema de substituição a passar pelo ponto de entrada.
Comprar em vez de desenvolver: o ciclo de vida da IA do responsável pela implantação
A maioria das organizações compra IA em vez de a desenvolver. As orientações da AEPD propõem, para as instituições da UE sujeitas ao Regulamento 2024/2509, um processo de contratação em quatro passos: publicação e transparência, convite à apresentação de propostas, seleção e adjudicação, e execução. É na execução que se repetem a verificação e validação, a implantação, a operação e monitorização, a validação contínua, a reavaliação e a desativação. O ciclo de vida da IA não desaparece quando se compra: muda de mãos e passa a depender do contrato.
As cláusulas que tornam o ciclo governável são poucas e concretas: aviso prévio de alterações de modelo ou de versão; acesso aos registos; cooperação em caso de incidente; documentação e instruções de utilização; regras de fim de vida, com devolução ou eliminação dos dados. A due diligence de fornecedores de IA é o momento certo para as exigir. Atenção ao artigo 25.º: pôr a sua marca num sistema de risco elevado ou modificá-lo substancialmente faz de si prestador.
Em Portugal, a ANACOM foi anunciada a 19 de setembro de 2025 como autoridade de fiscalização do mercado para o Regulamento da IA. A CNPD continua competente para os dados pessoais em todas as fases, da recolha dos dados de treino à eliminação final. As entidades públicas compram ao abrigo do Código dos Contratos Públicos, e o caderno de encargos é o sítio certo para fixar as cláusulas acima. Em Espanha, a AESIA já atua como autoridade de supervisão, e em Itália a lei 132/2025 designou a AgID e a ACN como autoridades nacionais.
Perguntas frequentes
<b>O que é a gestão do ciclo de vida da IA?</b>
É a governação de um sistema de IA em todas as suas fases, da ideia inicial à desativação. Define o responsável, quem autoriza a passagem de uma fase à seguinte, que provas sustentam cada decisão, como se triam as alterações e como se encerra o sistema. Para um sistema de risco elevado, é também a forma mais económica de produzir, com o tempo, a documentação exigida pelo Regulamento da IA.
<b>Quais são as fases do ciclo de vida da IA?</b>
Não há uma lista única. A ISO/IEC 22989, retomada pela AEPD, distingue início e análise, aquisição e preparação de dados, desenvolvimento, verificação e validação, implantação, operação e monitorização, validação contínua, reavaliação e desativação. O NIST AI RMF e a OCDE usam variantes próximas, e a ISO/IEC 42001 associa controlos a cada fase. O essencial é escolher um modelo, mapear os outros para ele e começar pelo inventário.
<b>O Regulamento da IA exige a gestão do ciclo de vida da IA?</b>
Não com esse nome, mas, na prática, sim para os sistemas de risco elevado. O artigo 9.º exige gestão de riscos contínua ao longo de todo o ciclo de vida, o artigo 15.º desempenho coerente nesse período, o artigo 12.º registos durante a vida útil e o artigo 72.º acompanhamento pós-comercialização. Somam-se as regras sobre modificação substancial, a retirada e a conservação documental durante 10 anos. Sem fases organizadas, o cumprimento dificilmente se prova.
<b>Qual é a diferença entre a gestão do ciclo de vida da IA e o MLOps?</b>
O MLOps é a camada de engenharia: automatiza o versionamento de dados e modelos, os testes, a publicação e a monitorização técnica. A gestão do ciclo de vida da IA é a camada de governação: decide se o sistema pode avançar, com que provas, quem assina e o que se conserva. O MLOps produz muitos dos registos de que a governação precisa, mas não decide se uma alteração é substancial nem se o sistema deve ser desativado.
<b>Quando é que uma alteração conta como modificação substancial?</b>
Quando surge depois da colocação no mercado ou em serviço, não foi prevista na avaliação da conformidade inicial e afeta a conformidade com os requisitos do capítulo III, secção 2, ou altera a finalidade prevista (artigo 3.º, ponto 23). Não contam as alterações predeterminadas e descritas no anexo IV, ponto 2, alínea f), para sistemas que continuam a aprender. A modificação substancial obriga a nova avaliação da conformidade e pode fazer de quem a introduz o novo prestador.
<b>O que acontece quando um sistema de IA é desativado?</b>
A decisão e o motivo ficam registados e os distribuidores e responsáveis pela implantação são informados. Se o sistema deixou de estar conforme, o prestador retira-o, desativa-o ou recolhe-o (artigo 20.º). A documentação técnica e a declaração de conformidade ficam guardadas 10 anos (artigo 18.º), o estatuto na base de dados da UE é atualizado e os dados pessoais são eliminados ou anonimizados. Um sistema de substituição recomeça o ciclo de vida da IA pelo ponto de entrada.
Conclusão
O ciclo de vida da IA não é um diagrama de engenharia para colar num diapositivo. É uma sequência de decisões que alguém tem de tomar, assinar e provar anos depois. O Regulamento da IA quase não usa a palavra, mas prende as obrigações a cada fase, e o Omnibus Digital fez do controlo de alterações o gatilho que traz os sistemas antigos para o âmbito. Quem planeia a desativação desde o primeiro dia, tria cada alteração e mantém um único modelo de fases chega à primeira auditoria com o dossiê feito; os outros reconstroem-no à pressa. Comece por inventariar os seus sistemas, nomear um responsável para cada um e fixar os seis pontos de decisão. Para o ver em formulários e aprovações por fase, consulte o nosso registo de sistemas de IA ou o guia de auditoria de IA.