Muitas pessoas olham para uma certificação e veem apenas um logótipo no rodapé de um site. A desconfiança não é infundada: sabe-se que há organizações que mantêm um conjunto de registos para mostrar ao auditor e trabalham de outra forma no resto do ano. Mas há forma de distinguir uma certificação que significa alguma coisa de outra que é mera “decoração”. Com a utilização generalizada da IA, essa distinção passou a ter consequências sérias.
Sempre que vamos a uma feira apresentar serviços de IA, há uma pergunta que se repete. Vem de empresários e de diretores de IT, e é quase sempre a primeira: “percebo que a IA faz muita coisa, mas, no meu contexto, em que é que isto me pode ajudar?” Há aqui uma dificuldade real em traduzir a tecnologia para o dia a dia de cada empresa. A pergunta seguinte é, tipicamente: “devo ter a IA dentro de portas, ou posso usar um serviço externo como o ChatGPT ou o Claude?” Quem faz estas perguntas está, no fundo, a tentar perceber em quem pode confiar.
A IA traz uma capacidade de execução que não tínhamos antes, mas isso também significa que os erros podem ganhar outra dimensão. Alguém que antes enviava um documento errado a um cliente pode agora gerar, em minutos, dezenas de respostas construídas sobre a mesma premissa errada. Há também riscos concretos na forma como os dados circulam e no que a tecnologia muda dentro de uma organização. Dizer às equipas “usem com bom senso” não é uma política.
Isto pesa em particular sobre quem vende serviços de IA. Um fornecedor tem de ter a IA bem implementada internamente antes de propor metodologias ou soluções aos seus clientes. Se não aplica a si próprio as boas práticas que recomenda, estará a expor os seus clientes a riscos elevados.
Foi essa a lógica que nos levou à ISO 42001. A norma serve para responder a uma pergunta simples: o que se está mesmo a passar dentro da empresa com a IA? Saber que ferramentas estão a ser usadas, para que servem e quem as autorizou. Analisar cada uma antes de começar a ser utilizada. Ter políticas escritas e conhecidas por todos. Segurança ativada, não apenas prevista num documento. Análise de risco caso a caso, em vez de uma regra genérica para tudo.
Quem está a começar a implementação da IA agora tem duas opções: implementar a IA à sua maneira e documentar as regras depois, ou seguir as normas desde o primeiro dia. Nós escolhemos a segunda e não atrasámos o processo por causa disso. Na prática, ter um referencial desde o início ajudou-nos a tomar decisões à medida que fomos implementando a IA, em vez de tentarmos criar regras para uma realidade que já estava instalada. Houve duas condições que ajudaram: a decisão partiu da administração e a gestão de topo foi a primeira a usar as ferramentas. Quem trata isto como um projeto do departamento de IT arrisca-se a ter decisões de risco tomadas por quem não tem autoridade para tal.
Mas é natural que exista sempre a dúvida sobre se uma entidade certificada trabalha realmente como diz. O que a certificação garante é que houve um sistema montado e que alguém independente o verificou. Ainda assim, qualquer cliente ou potencial cliente consegue fazer algumas validações que ajudam a perceber a maturidade do fornecedor com quem está a trabalhar. O próprio certificado identifica o âmbito, normalmente em letra pequena e ao qual quase ninguém presta atenção. Diz que atividades e que locais estão cobertos. Um certificado que abrange apenas o departamento de compras não cobre a operação, nem o suporte, nem o resto da empresa. Também vale a pena confirmar a validade e a data da última auditoria.
Aquilo de que as empresas realmente precisam dos seus fornecedores de implementação de IA é que o trabalho seja bem feito e que possam confiar em quem o faz. E é aqui que voltamos à pergunta que, tipicamente, os responsáveis de TI ou os gestores das empresas colocam: o que é que a IA pode fazer no contexto de cada organização? Para responder, não basta conhecer a tecnologia. É preciso perceber primeiro o negócio, identificar onde a IA pode ser realmente útil, saber que dados são críticos, avaliar os riscos e decidir, caso a caso, o que pode ser tratado num serviço externo e o que deve ficar dentro de portas.
Na maioria das situações, o resultado é um modelo híbrido, com IA interna para algumas coisas e IA externa para outras. Foi o caminho que seguimos. Mas há exceções claras: quando o conhecimento interno de um cliente é o seu principal ativo, expor esse conhecimento externamente pode representar um risco que justifica o investimento numa solução interna. Para chegar a essa conclusão é preciso primeiro perceber o cliente e aquilo que pretende resolver. A tecnologia vem depois.
Quem já percorreu este caminho por dentro tem uma experiência diferente quando chega o momento de o fazer com um cliente. Conhece as dúvidas que aparecem, as decisões que têm de ser tomadas e os problemas que nem sempre são evidentes no início. Por isso, a quem procura um parceiro para projetos de IA, sugiro algumas perguntas que ajudam a perceber a maturidade do fornecedor:
- Que ferramentas de IA utilizam internamente e com que objetivo?
- Que mecanismos usam para proteger dados sensíveis?
- Como impedem que os vossos colaboradores usem ferramentas de IA não autorizadas?
- Como decidem que dados podem ser tratados por serviços externos de IA e quais devem permanecer em sistemas internos?
Se as respostas forem vagas, é provável que o parceiro não esteja preparado para o projeto que pretendem iniciar.
Daniela Costa, COO da Eurotux
