Inteligência artificial
Inteligência artificial como serviço gerido para o mercado médio
A maior parte das empresas de dimensão média não precisa de uma equipa de ciência de dados. Precisa de dois ou três processos automatizados, com alguém responsável quando falham.
Equipa editorial da Corpshore Portugal
Escrito pela equipa que monta estas operações. Sem autoria individual atribuída: o que está aqui é trabalho revisto internamente, não opinião pessoal.
Publicado a
Porque é que os projetos próprios encalham?
Porque o protótipo é a parte fácil. O que falha depois é a operação: quem corrige quando o modelo erra, quem reavalia quando os dados mudam, quem responde ao cliente que recebeu a resposta errada e quem documenta tudo isto para o regulador. Nenhuma dessas perguntas se resolve com uma demonstração.
Num serviço gerido, essas responsabilidades estão atribuídas por contrato antes de o primeiro caso passar pelo sistema. É a diferença principal e vale mais do que qualquer ganho de exatidão.
Por onde começar sem arriscar?
Por trabalho de triagem e de classificação, onde o erro é barato e visível: encaminhar mensagens por assunto, extrair campos de documentos, propor respostas que uma pessoa aprova. Mantém-se sempre a revisão humana nos casos que afetam direitos do cliente.
O Regulamento da Inteligência Artificial da União Europeia entra em aplicação por fases e classifica os sistemas por risco. Para a maior parte destes casos o risco é limitado, mas as obrigações de transparência aplicam-se: o utilizador tem de saber que está a interagir com um sistema automatizado.
Como medir se está a resultar?
Pelo tempo total do processo e pela taxa de reabertura, não pela percentagem de casos automatizados. Automatizar oitenta por cento e reabrir metade deles é pior do que automatizar quarenta e fechar quase todos.
Vale também a pena medir o tempo que a supervisão consome. Um sistema que automatiza metade do volume e obriga a uma camada de revisão do mesmo tamanho da equipa anterior não libertou capacidade nenhuma, apenas mudou o tipo de trabalho, e isso só aparece se alguém contar as horas dos dois lados.
Que processos são bons candidatos?
Processos com volume alto, regras estáveis e um resultado verificável dentro de horas. Encaminhamento de mensagens por assunto, extracção de campos de facturas e de guias, classificação de pedidos por tipo, e proposta de resposta a perguntas frequentes com aprovação humana antes de sair.
O critério que mais importa é o custo do erro. Se uma classificação errada significa que a mensagem chega à equipa errada e alguém a reencaminha em dois minutos, o erro é barato e visível e o processo é um bom candidato. Se significa que um cliente recebe uma decisão errada sobre um direito, não é.
O segundo critério é a existência de exemplos históricos. Um processo que corre há dois anos com registo do que foi decidido tem material de avaliação. Um processo novo não tem, e começar por automatizar algo que nunca foi feito manualmente é resolver dois problemas desconhecidos ao mesmo tempo.
Como se constrói o conjunto de avaliação?
A partir de casos reais já decididos, escolhidos para cobrir a distribuição real e não a distribuição conveniente. Duzentos a quinhentos casos chegam para a maior parte dos processos de mercado médio, desde que incluam os casos limite na proporção em que eles ocorrem.
A parte que se faz mal é a rotulagem. Se duas pessoas experientes discordam sobre a decisão correcta em quinze por cento dos casos, nenhum sistema vai fazer melhor do que isso, e o número é informação valiosa: mede quanto do processo é realmente ambíguo. Vale a pena medi-lo antes de medir o sistema.
O conjunto de avaliação deve ser construído antes de qualquer trabalho de automatização e mantido separado. Um conjunto que foi usado para afinar o sistema deixa de servir para o avaliar, e a tentação de o reutilizar é forte precisamente quando os resultados começam a ser bons.
O que exige o Regulamento da IA na prática?
Classificação por risco, primeiro. A maior parte dos casos de mercado médio cai em risco limitado, onde a obrigação central é de transparência: o utilizador tem de saber que está a interagir com um sistema automatizado, e conteúdo gerado artificialmente tem de ser identificável como tal.
Alguns casos sobem para risco elevado, sobretudo quando o sistema participa em decisões sobre emprego, acesso a serviços essenciais, crédito ou avaliação de pessoas. Aí acrescem obrigações substanciais de gestão de risco, qualidade de dados, documentação técnica, registo de eventos e supervisão humana efectiva.
Supervisão humana efectiva é a expressão que mais frequentemente é cumprida só no papel. Uma pessoa que aprova trezentas propostas por hora não está a supervisionar, está a carimbar. Se a taxa de rejeição humana é próxima de zero, ou o sistema é perfeito ou a supervisão não existe, e a primeira hipótese é rara.
Quanto custa e em quanto tempo se vê retorno?
Para dois ou três processos de mercado médio, o arranque leva tipicamente entre oito e dezasseis semanas: quatro a seis a descrever o processo e a construir o conjunto de avaliação, quatro a seis a montar e a afinar, e o resto em funcionamento assistido antes de reduzir supervisão.
O retorno raramente vem de redução de pessoas e quase sempre de tempo de ciclo e de capacidade libertada. Um processo que demorava dois dias e passa a demorar duas horas muda o que o negócio consegue prometer, e isso vale mais do que a diferença de custo directo na maior parte dos casos.
O custo recorrente que as pessoas esquecem é a manutenção. Os dados mudam, os processos mudam, e um sistema que não é reavaliado degrada-se silenciosamente. Orçamentar zero para manutenção é a forma habitual de ter um projecto excelente no primeiro ano e um problema no terceiro.
Que sinais indicam que se deve travar?
Taxa de reabertura a subir enquanto a taxa de automatização sobe. É o sinal mais claro de que o sistema está a fechar casos que não estão resolvidos, e é invisível em qualquer painel que só meça volume automatizado. Vale mais automatizar quarenta por cento e fechar quase tudo do que oitenta e reabrir metade.
Reclamações concentradas num tipo de caso. Se as queixas se agrupam num padrão, o sistema está a errar sistematicamente nesse padrão e a resposta correcta é suspender a automação desse tipo de caso enquanto se investiga, não ajustar um limiar global e esperar.
E revisores humanos que deixaram de discordar. Quando a taxa de correcção humana cai a pique sem que nada tenha mudado no sistema, normalmente não é o sistema que melhorou: é a supervisão que se tornou rotina. Vale a pena introduzir casos de controlo conhecidos para medir se a revisão ainda está a acontecer.
Como se desenha a supervisão humana?
Com uma regra explícita sobre que casos exigem aprovação antes de sair, escrita por tipo de caso e não por limiar de confiança do sistema. Limiares de confiança são úteis e não são um critério defensável sozinhos: um sistema pode estar muito confiante e muito errado, e a diferença não é observável de fora.
Com tempo suficiente para que a revisão seja real. Se o desenho da operação implica que cada revisor aprove uma proposta a cada dez segundos, a supervisão é nominal. Dimensionar a camada de revisão pelo tempo que uma revisão honesta demora é o que separa conformidade de teatro.
Com poder real de rejeitar e de escalar. Um revisor que pode corrigir mas não pode parar a automação de um tipo de caso não está a supervisionar o sistema, está a limpar o que ele produz. A autoridade para suspender tem de existir e tem de ser usada sem custo pessoal.
E com medição da própria supervisão. Casos de controlo conhecidos inseridos na fila de revisão medem se a revisão está de facto a acontecer. É a única forma de detectar a deriva para o carimbo automático, que acontece sempre e não se anuncia.
Que documentação tem de existir?
A descrição do sistema e da sua finalidade, em linguagem que alguém fora da equipa técnica consiga avaliar. Se a documentação só é compreensível por quem construiu o sistema, não serve para supervisão de gestão nem para um regulador, que são os dois destinatários que importam.
A proveniência dos dados usados, com base legal para cada utilização, e a descrição do conjunto de avaliação e dos resultados obtidos por categoria de caso. Resultados agregados não chegam: a pergunta que um regulador faz é sobre o grupo em que o sistema se comporta pior.
O registo de eventos, com retenção definida, que permita reconstruir porque é que um caso concreto foi decidido de determinada forma. Sem isto, responder a uma contestação individual é impossível, e a contestação individual é o cenário mais provável de todos.
E o registo das alterações: quando o sistema foi alterado, por quem, porquê, e qual foi o efeito medido. Um sistema que muda sem registo torna qualquer análise histórica inválida, e a primeira vez que isso importa é sempre durante uma investigação.
Perguntas frequentes
- Preciso de cientistas de dados?
- Para a maior parte dos casos de mercado médio, não. Precisa de processos definidos e de responsabilidade atribuída.
- O Regulamento da IA aplica-se a mim?
- Aplica-se, com obrigações proporcionais ao risco. Transparência é a mais comum.
- Deve haver sempre revisão humana?
- Nos casos que afetam direitos do cliente, sim, e isso deve ficar escrito.
- Qual é a métrica certa?
- Tempo total do processo e taxa de reabertura, não percentagem automatizada.
- Quem responde quando o sistema erra?
- Num serviço gerido, o fornecedor, com a responsabilidade atribuída por contrato antes de abrir.
- Com que casos começar?
- Triagem e classificação, onde o erro é barato e visível e a correção é imediata.
- O utilizador tem de saber que é automatizado?
- Tem, e essa é a obrigação de transparência mais comum do Regulamento da IA.
- Quando se reavalia o sistema?
- Quando os dados ou o processo mudam, e em revisão periódica marcada no contrato.
Vamos ver os números do seu caso
Diga-nos que processos quer externalizar, em que línguas e com que volumes. Devolvemos uma estimativa em euros e um desenho de operação, sem compromisso.
Respondemos em menos de 6 horas em dias úteis. Se preferir escrever: info@corpshore.solutions