Software GRC: o que muda com a IA

O essencial

• Um software GRC é o arquivo único onde convergem políticas, riscos, controlos, obrigações e as provas que os ligam entre si. O seu valor está no modelo de dados, não no painel.
• O que a IA alterou foi o âmbito desse modelo: os sistemas de IA que uma organização desenvolve ou adquire constituem já uma categoria de ativos regulados por direito próprio.
• O artigo 17.º do regulamento europeu da IA enumera doze elementos que o sistema de gestão da qualidade de um prestador tem de documentar. Lido como um caderno de compras, esse elenco descreve o que uma ferramenta tem de conter.
• O Ómnibus digital adiou para 2 de dezembro de 2027 o prazo dos sistemas de risco elevado do anexo III. Mudou o prazo, não o tempo exigido para construir uma cadeia de provas credível.
• O critério de escolha não é o número de módulos, mas sim que os resultados resistam ao exame de um organismo notificado ou de uma autoridade de fiscalização do mercado.

O que faz realmente um software GRC

Um software GRC constitui o arquivo único onde constam as políticas de uma organização, os riscos que aceitou ou recusou, os controlos que tratam esses riscos, as obrigações a que tais controlos respondem e as provas de que cada controlo funcionou efetivamente. As três letras designam três disciplinas nascidas em direções distintas. A ferramenta é precisamente aquilo que as obriga a partilhar uma mesma estrutura. Essa estrutura constitui o produto. Uma governação sem dados de risco reduz-se a documentos que ninguém lê. Um risco sem ligação aos controlos gera um registo que nunca muda nada. Uma conformidade sem provas permanece uma afirmação. Enquanto as três dimensões viverem em folhas de cálculo separadas, cada auditoria torna-se um exercício de reconciliação e cada pergunta do regulador transforma-se num projeto. Quando partilham um único modelo de dados, uma pergunta do tipo «que controlos tratam este risco, quem responde por eles, quando foram testados pela última vez e onde está a prova» obtém resposta em minutos e não em semanas. É também a razão pela qual a categoria resiste às definições simples. Dois produtos podem ambos apresentar-se como plataforma GRC sem partilharem quase nada, porque um está construído em torno da distribuição de políticas e da sua tomada de conhecimento, e o outro em torno do ensaio dos controlos e da condução de auditorias. A pergunta útil nunca é se se trata de uma ferramenta GRC, mas sim o que o seu modelo de dados torna barato e o que torna dispendioso.

Porque o modelo de dados importa mais do que o painel

Nas demonstrações comerciais o painel ocupa o primeiro plano, porque se mostra bem. Situa-se, porém, a jusante. Um mapa de calor produz-se sem dificuldade quando riscos, controlos e resultados de ensaios estão corretamente ligados, e torna-se impossível de produzir com honestidade quando não estão. As perguntas que verdadeiramente sustentam uma avaliação dizem respeito à estrutura. Pode um mesmo controlo satisfazer vários referenciais em simultâneo, ou impõe a ferramenta um controlo duplicado por cada referencial? Pode uma obrigação ser seguida até ao artefacto concreto que a cumpre? Pode um risco ser associado a um ativo e não apenas a um processo de negócio? Dessas respostas depende que a ferramenta reduza o trabalho ou se limite a deslocá-lo. O nosso guia sobre governação da IA expõe o modelo operacional que esta estrutura tem de sustentar.

O modelo de capacidades OCEG e o lugar real da ferramenta

A maioria das apresentações desta categoria acaba por citar o GRC Capability Model da OCEG, publicado como Red Book. Organiza a disciplina em quatro componentes: Learn, Align, Perform e Review, sob o lema da Principled Performance. Learn consiste em compreender o contexto, a cultura e as partes interessadas. Align liga objetivos, estratégia e apetência pelo risco. Perform abrange a execução dos controlos. Review mede o que efetivamente resultou. O modelo está disponível na OCEG. A leitura honesta, aquela que a maioria dessas apresentações evita, cabe numa frase: o software instrumenta bem Perform e Review, e não consegue de todo fabricar Align. Uma ferramenta sabe registar uma declaração de apetência pelo risco. Não dirá se a organização partilha realmente essa apetência, nem se a direção a poria de lado sob pressão comercial. Adquirir uma ferramenta antes de decidir o que a organização está de facto disposta a aceitar produz uma versão notavelmente bem documentada de um desacordo por resolver. Com a IA esta distinção pesa mais do que pesava com os controlos financeiros, porque as decisões sobre IA são tomadas muito mais abaixo na organização. Um responsável de produto pode inserir um modelo num percurso voltado para o cliente numa tarde. Se a fase Align não teve lugar, a ferramenta regista as consequências em vez de orientar as escolhas. Isso explica igualmente a indefinição das fronteiras da categoria. Um software GRC é uma peça de uma cadeia de controlo mais vasta, que inclui gestão de identidades, registo de eventos, registos de modelos e supervisão de segurança, uma repartição que expomos na nossa análise sobre a plataforma de conformidade face ao restante da cadeia.

O que a IA muda: o sistema passa a ser o ativo regulado

Até há pouco tempo o âmbito de um programa GRC abrangia processos, fornecedores, controlos e informação financeira. A IA acrescenta um objeto para o qual o modelo não foi concebido: um ativo probabilístico em vez de determinístico, que se degrada em silêncio à medida que o mundo se afasta dos seus dados de treino, e que é regulado sistema a sistema em vez de processo a processo. Daqui decorrem três consequências. A primeira respeita ao inventário, que passa a ser a restrição determinante. Não se classifica, não se controla nem se prova aquilo cuja existência se desconhece, e a adoção não declarada é a norma e não a exceção. Tudo o que não se vê fica fora do conjunto de controlos redigidos, e esse é o problema concreto que está por detrás da shadow AI. A segunda consequência transforma a classificação num ato jurídico e não numa comodidade interna. Segundo o regulamento europeu, o facto de um sistema recair nas práticas proibidas, nos sistemas de risco elevado, nos sujeitos apenas a obrigações de transparência ou fora de qualquer regime específico determina as obrigações que lhe são aplicáveis. Essa classificação tem de ser registada, fundamentada e reapreciada sempre que o sistema evolui. A terceira consequência põe fim ao carácter periódico do registo de riscos. Um controlo ensaiado uma vez por ano é uma resposta razoável para um processo de aquisição. Torna-se insuficiente para um modelo cujo comportamento pode deslocar-se após uma atualização do fornecedor de que ninguém foi avisado. O nosso guia de gestão de riscos de IA precisa o que significa contínuo na prática.

Do GRC potenciado por IA ao GRC sobre a IA

Quase todos os produtos do mercado exibem já funcionalidades de IA: resumir políticas, redigir descrições de controlos, sugerir avaliações de risco, triar questionários. Uma parte delas elimina trabalho de facto. Trata-se, contudo, de um assunto inteiramente distinto daquele sobre o qual as autoridades interrogam. O GRC potenciado por IA significa que o fornecedor usa um modelo para acelerar o seu próprio software. O GRC sobre a IA significa que a sua organização consegue demonstrar o domínio dos sistemas de IA que explora. Uma ferramenta pode ser excelente no primeiro aspeto e inútil no segundo. Toda a distinção reside na preposição, e vale a pena ser direto com os fornecedores sobre qual dos dois está a ser mostrado. Há ainda um ponto de segunda ordem. Se um modelo contribui para produzir as suas provas de controlo, esse modelo entra por sua vez no âmbito. Uma prova gerada por um sistema não validado não vale mais do que o sistema que a produziu.

O regulamento europeu redige o caderno de encargos

O aspeto mais útil do regulamento europeu da IA, para quem avalia ferramentas, está na sua precisão invulgar quanto ao que tem de existir por escrito. Os artigos 8.º a 15.º fixam os requisitos aplicáveis aos sistemas de risco elevado: sistema de gestão de riscos (artigo 9.º), dados e governação de dados (artigo 10.º), documentação técnica (artigo 11.º), conservação de registos (artigo 12.º), transparência e informação aos utilizadores (artigo 13.º), supervisão humana (artigo 14.º), exatidão, solidez e cibersegurança (artigo 15.º). O artigo 16.º enumera depois as obrigações do prestador: cumprir esses requisitos, identificar-se no sistema, dispor de um sistema de gestão da qualidade, conservar a documentação, conservar os registos gerados automaticamente, submeter-se à avaliação da conformidade, elaborar uma declaração UE de conformidade, apor a marcação CE, registar o sistema, adotar as medidas corretivas necessárias, cooperar com as autoridades nacionais competentes e cumprir os requisitos de acessibilidade. O artigo 17.º faz surgir um caderno de compras quase à letra. O sistema de gestão da qualidade do prestador tem de estar documentado e incluir no mínimo: uma estratégia de conformidade regulamentar que abranja os procedimentos de avaliação da conformidade; as técnicas de conceção, desenvolvimento e controlo da qualidade; os procedimentos de exame e ensaio; as especificações técnicas; os sistemas de gestão de dados; um sistema de gestão de riscos; um sistema de acompanhamento pós-comercialização nos termos do artigo 72.º; os procedimentos de comunicação de incidentes graves nos termos do artigo 73.º; um processo de comunicação com as autoridades; um sistema de conservação de registos; a gestão de recursos; e um quadro de responsabilização que fixe as responsabilidades da direção e do pessoal. Doze elementos, cada um dos quais tem de estar algures e poder ser apresentado quando solicitado. Trata-se do caderno de encargos de um arquivo, chame-lhe alguém assim ou não. O artigo 9.º precisa a forma do trabalho sobre o risco. A gestão de riscos é um processo iterativo contínuo ao longo de todo o ciclo de vida: identificar e analisar os riscos para a saúde, a segurança e os direitos fundamentais, avaliar os riscos que surgem durante a utilização, avaliar os riscos revelados pelos dados de acompanhamento pós-comercialização e adotar em conformidade as medidas adequadas. As finalidades também estão fixadas: eliminar ou reduzir o risco na medida tecnicamente possível, mitigar o que não puder ser eliminado, prestar a informação de transparência e formar os responsáveis pela implantação quando adequado. O próprio risco define-se como a combinação da probabilidade de um dano e da sua gravidade. Uma nuance desarma a objeção habitual de que tudo isto só diz respeito às grandes organizações. O artigo 17.º, n.º 2, exige que a aplicação do sistema de gestão da qualidade seja proporcionada à dimensão da organização do prestador, e o considerando 146 contempla expressamente uma versão simplificada para as microempresas. A proporcionalidade incide sobre a quantidade de processo, não sobre a existência das obrigações. Os nossos recursos sobre o regulamento europeu da IA abordam em detalhe as questões de classificação.

O prazo mudou, o tempo de construção não

O calendário deslocou-se em 2026. O Ómnibus digital sobre IA adiou para 2 de dezembro de 2027 as obrigações dos sistemas de risco elevado autónomos do anexo III, e para 2 de agosto de 2028 as relativas à IA integrada em produtos já abrangidos pela legislação europeia de segurança dos produtos. Várias datas não mudaram: as obrigações de transparência e de rotulagem de conteúdos do artigo 50.º aplicam-se desde 2 de agosto de 2026, as relativas aos modelos de IA de finalidade geral desde 2 de agosto de 2025, e as proibições do artigo 5.º desde 2 de fevereiro de 2025. As análises da Cloud Security Alliance e da sociedade Gibson Dunn coincidem nessas datas. Ler esse adiamento como uma folga é um erro, por uma razão muito concreta. O acompanhamento pós-comercialização e a conservação de registos são obrigações retrospetivas. Quando em 2028 uma autoridade perguntar como se comportou um sistema, a resposta construir-se-á a partir de registos que era preciso captar enquanto o sistema funcionava. Uma organização que comece a recolher no final de 2027 disporá de um sistema de gestão conforme e de nenhum histórico para nele verter. O prazo assinala o momento em que é preciso poder mostrar a cadeia, o que coloca bastante mais cedo a decisão de recolher.

ISO 42001 e NIST AI RMF: a camada de controlos

O regulamento diz o que tem de ser verdade. Não entrega um conjunto de controlos. Duas referências preenchem essa lacuna, e qualquer software GRC sério tem de sustentar ambas sem duplicar o trabalho. A norma ISO/IEC 42001 especifica um sistema de gestão da IA, construído como as demais normas de sistemas de gestão, e é certificável. O ponto conta tanto no plano comercial como no interno, pois um certificado é uma prova transferível numa conversa de aquisição. Encaixa bem nos elementos do artigo 17.º, e daí que tantos prestadores façam dele o esqueleto do seu sistema da qualidade. Tratamos a norma em ISO 42001 explicada. O NIST AI Risk Management Framework é voluntário e tem outra forma: quatro funções, Govern, Map, Measure e Manage, que dão às equipas um vocabulário comum para falar de risco de IA sem abrir antes uma discussão terminológica. A sua força está em ordenar a análise, a sua fraqueza no valor probatório perante uma auditoria, exatamente o inverso de uma norma certificável. O nosso guia do NIST AI RMF percorre as quatro funções. A consequência para a escolha de ferramenta é concreta. A maioria das organizações responde ao mesmo tempo a um regulamento, a uma norma certificável e a um quadro voluntário, muitas vezes além de certificações de segurança já existentes. Uma ferramenta que atribua um controlo a um único referencial obriga a recolher várias vezes a mesma prova. Uma ferramenta que modele o controlo uma vez e o ligue a várias obrigações transforma uma multiplicação numa adição. Esta única pergunta separa as ferramentas que acompanham o crescimento daquelas que triplicam a carga em silêncio.

Uma lista de capacidades para as ferramentas na era da IA

O que se segue é o que convém pôr à prova ao avaliar um software GRC, com a obrigação a que cada capacidade responde. A lista raciocina deliberadamente em capacidades e não em módulos, porque os nomes dos módulos variam entre produtos ao passo que as obrigações não variam.

Duas linhas concentram na prática a maior parte da dificuldade. O registo automático é o ponto de rutura das ferramentas concebidas para a conformidade de processos, construídas para validações humanas periódicas e não para fluxos de eventos de máquina. A rastreabilidade da cadeia de fornecimento é onde a maioria das organizações descobre que não sabe responder a perguntas elementares sobre um modelo que não treinou, exatamente a lacuna tratada no nosso trabalho sobre auditabilidade.

Provas que resistem a uma auditoria

A maioria dos problemas de prova não são ausências. São artefactos que existem e ainda assim não resistem ao exame, segundo quatro modos de falha recorrentes. O nosso guia sobre auditoria de sistemas de IA detalha o que os avaliadores procuram realmente. A temporalidade vem primeiro. Uma captura de ecrã demonstra que um estado existia no momento em que alguém a tirou, não que um controlo funcionou ao longo de um período. Segue-se a atribuição: uma exportação sem autor, sem versão de sistema e sem marca temporal não se liga a nada. A mutabilidade constitui o terceiro modo, pois uma folha de cálculo alterável a posteriori demonstra bastante menos do que o seu conteúdo sugere. A rastreabilidade forma o quarto e mais frequente: um artefacto que não possa ser ligado à obrigação concreta que cumpre deixa o avaliador a adivinhar, e os avaliadores não adivinham a seu favor. Os trabalhos do COSO sobre controlo interno aplicado à IA generativa trazem aqui uma distinção que convém retomar. Quando a direção se apoia numa saída de modelo como parte da prova de um controlo, o padrão aplicável a essa prova eleva-se. Refazer pessoalmente uma verificação não equivale a aceitar a conclusão de um modelo, e o encargo documental difere em consequência: a instrução, a configuração e a versão do modelo passam a integrar o processo. A mesma publicação formula uma observação conexa que costuma surpreender as equipas, a saber, que modelos, configurações, artefactos de afinação, incorporações e índices de recuperação deveriam ser tratados como elementos de configuração sujeitos a controlo de acessos e gestão de alterações, e não como conteúdo. O ensaio prático aplicável a qualquer ferramenta faz-se em segundos. Tome um controlo, suba até à obrigação a que responde e desça depois ao artefacto que atesta o seu funcionamento no trimestre anterior. Se esse percurso exigir mais de dois cliques, ou se algum passo assentar na memória de alguém, a ferramenta é um armário de processos e não um arquivo de referência.

Comprar, alargar ou ambos

Para se dotar de um software GRC que cubra a IA apresentam-se três opções honestas, e a escolha depende do existente. Alargar uma plataforma já implantada justifica-se quando funciona um programa maduro, quando o fornecedor oferece um módulo de IA sólido e não um registo de riscos rebatizado, e quando a biblioteca de controlos existente é realmente reutilizável. A vantagem está num único sistema e num único conjunto de hábitos. O risco reside num módulo que modela os sistemas de IA como ativos comuns, e que por isso falha na classificação, no registo e na proveniência dos modelos. Um sistema dedicado à governação da IA justifica-se quando a IA ocupa um lugar central no produto, quando as obrigações são suficientemente específicas para que as estruturas de controlo genéricas não sirvam, ou quando não existe nada de maduro para alargar. A vantagem está num modelo de dados concebido para o problema. O custo é um segundo sistema e um trabalho de integração de que ninguém gosta. A abordagem híbrida é o desfecho mais frequente e o menos comentado. A plataforma histórica permanece o arquivo de referência da empresa, enquanto um sistema especializado trata as obrigações próprias da IA e faz subir um estado consolidado. Funciona quando a fronteira é traçada deliberadamente, e produz dois registos rivais quando não o é. Seja qual for a via escolhida, fixe essa fronteira antes da conversa comercial e não durante. A nossa página de software de conformidade para IA expõe a nossa abordagem à parte especializada.

Perguntas frequentes

Qual é um exemplo de software GRC? A categoria abrange várias formas de produto. As plataformas GRC empresariais centralizam registos de riscos, ensaio de controlos e condução de auditorias para grandes organizações reguladas. As ferramentas de automatização da conformidade concentram-se na recolha contínua de provas face a certificações de segurança. Os sistemas de gestão de políticas cobrem redação, distribuição e tomada de conhecimento. Os sistemas dedicados à governação da IA modelam os sistemas de IA, a sua classificação e as suas obrigações. A maioria das organizações utiliza mais do que um, pelo que a comparação útil é qual deles sustenta o arquivo de referência e quais o alimentam. GRC e auditoria informática são a mesma coisa? Não, embora sejam confundidos com frequência porque ambos olham para os mesmos controlos. O GRC é a disciplina operacional contínua: fixar a política, manter o registo de riscos, executar controlos e recolher provas sem interrupção. A auditoria informática é uma avaliação independente e periódica sobre se essa disciplina funciona. Um programa GRC bem conduzido torna as auditorias menos dispendiosas, uma vez que as provas já existem de forma estruturada. As constatações da auditoria regressam depois ao registo de riscos. A relação é cíclica, mas os papéis permanecem deliberadamente separados, e a independência é a razão. O Jira é uma ferramenta GRC? Por si só não. O Jira acompanha tarefas, e boa parte do trabalho GRC consiste em tarefas: ações de correção, ensaios de controlos, pedidos de evidência. Muitas equipas começam por fazer passar por ali a sua atividade de conformidade. O que falta é o modelo de dados subjacente, ou seja, objetos de primeiro nível para riscos, controlos, obrigações e provas, com as relações entre eles. Os itens com etiquetas aproximam-se disso até ao dia em que um avaliador pergunta que controlos tratam um dado risco e onde está a prova. O Jira funciona bem ao lado de um arquivo de referência, e mal como tal. O GRC exige saber programar? Em geral não para o trabalho quotidiano. As ferramentas atuais configuram-se por interface, e as partes exigentes do ofício são analíticas e não técnicas: classificar bem os sistemas, redigir controlos realmente verificáveis, decidir o que constitui prova suficiente. A programação ganha relevância nas extremidades, sobretudo nas integrações que recuperam provas automaticamente a partir de plataformas na nuvem, registos de modelos ou sistemas de registo de eventos. Essa automatização é o que torna viável o acompanhamento contínuo em escala, pelo que alguma capacidade técnica na equipa continua a ser uma vantagem concreta mesmo onde não seja exigida. O que é melhor, um SOC ou um GRC? Respondem a perguntas distintas e não são alternativas. Um centro de operações de segurança deteta e trata ameaças quase em tempo real. O GRC estabelece o que deve ser dominado, porquê, e se os controlos funcionaram ao longo de um período. Um SOC produz provas e incidentes que um programa GRC consome, e um programa GRC fixa as políticas e a apetência pelo risco dentro das quais um SOC opera. As organizações que os tratam como rubricas orçamentais rivais acabam com uma deteção que ninguém ligou a uma obrigação, ou com obrigações que nada vigia. As ferramentas GRC cobrem o regulamento europeu da IA? Cada vez mais o afirmam, e essas afirmações merecem ser verificadas. Peça para ver um inventário dos sistemas de IA com classificação por sistema e fundamentação registada, provas ligadas a artigos concretos e não a uma família genérica de controlos, registos de máquina conservados em vez de atestações humanas, e uma gestão de incidentes graves cadenciada pelos prazos regulamentares. Muitos produtos satisfazem o primeiro ponto e tropeçam nos restantes. Um fornecedor que reivindique essa cobertura deveria conseguir percorrer um sistema desde o registo até um processo legível por um avaliador.

Conclusão

A categoria não mudou de nome. Mudou de âmbito. Um software GRC era julgado pelo modo como tratava processos, fornecedores e controlos financeiros; passou a ser julgado pela sua capacidade de tratar também um sistema de IA como objeto governado de primeiro nível, com uma classificação, um conjunto de controlos, uma cadeia de registos e um responsável. O regulamento tornou os requisitos invulgarmente legíveis. O artigo 17.º enumera o que tem de estar documentado, o artigo 12.º exige que os registos existam, o artigo 72.º prolonga o acompanhamento após a implantação, e o adiamento dos prazos significa que a cadeia de provas tem de arrancar muito antes da data pela qual se será medido. Avalie em conformidade: não pelo número de módulos, mas pela solidez do percurso que liga a obrigação ao controlo e depois ao artefacto datado, quando alguém com autoridade o percorre. Se está a conduzir essa avaliação especificamente para sistemas de IA, a nossa plataforma de conformidade para IA foi construída em torno das obrigações artigo a artigo descritas acima.