Rent-a-car: o contrato não prova quem conduzia
«Chegou uma notificação para esta matrícula. Quem tinha o carro àquela hora?» Abres o programa de aluguer, procuras o contrato e encontras um nome. Só que esse nome pode ser o do titular do contrato, não o de quem estava ao volante. Se havia um condutor adicional, uma devolução tardia ou uma troca de viatura, a resposta exige mais do que copiar o primeiro resultado.
Num rent-a-car dos Açores ou da Madeira, o problema é concreto: reunir os registos certos, perceber o que demonstram e preparar a revisão por quem responde à notificação. Uma IA fundada nos teus dados, só de leitura — read-only — e auditada pode ajudar nessa conferência. Não pode transformar uma correspondência contratual numa certeza sobre quem conduzia.
Há três perguntas diferentes dentro da mesma notificação
A primeira é: que viatura está referida? A matrícula permite começar a pesquisa. A segunda é: que contrato ou movimento operacional corresponde à data e hora indicadas? Aqui entram entregas, devoluções, prolongamentos e substituições. A terceira é: quem conduzia efetivamente nesse momento?
O teu sistema pode responder bem às duas primeiras e não conter informação suficiente para a terceira. Um contrato com dois condutores autorizados demonstra que ambos estavam registados nessa qualidade. Não demonstra qual deles conduzia numa determinada passagem. Mesmo um único condutor registado não transforma, por si só, o contrato numa observação do que aconteceu na estrada.
O artigo 171.º do Código da Estrada distingue situações envolvendo o titular do documento de identificação do veículo, a pessoa coletiva, o locatário e o condutor. Essa distinção interessa ao desenho do software: não devem acabar todos no mesmo campo chamado «responsável». As referências a modalidades específicas de locação também não devem ser aplicadas automaticamente a qualquer aluguer de curta duração.
Este artigo trata da organização da informação, não da determinação de responsabilidade ou da resposta jurídica. O procedimento e os prazos têm de ser conferidos na notificação recebida e na legislação vigente. Uma ambiguidade nos dados não suspende uma obrigação de resposta; exige que o responsável a trate, com apoio jurídico quando necessário.
A hora prevista não é a hora da entrega
Imagina este exemplo inteiramente fictício. Uma notificação refere uma ocorrência em 24 de outubro, às 10h12. Para a mesma matrícula, o programa contém estes registos:
| Registo | Informação disponível |
| — | — |
| Contrato C417 | Devolução prevista às 10h00; receção efetiva registada às 10h15 |
| Condutores de C417 | Titular e um condutor adicional autorizado |
| Contrato C418 | Entrega prevista às 10h00; entrega efetiva registada às 10h40 |
Uma pesquisa baseada apenas no calendário previsto pode apresentar C418: o aluguer anterior terminava às 10h00 e o seguinte começava à mesma hora. Mas os movimentos efetivos contam outra história. Às 10h12, a receção da viatura de C417 ainda não estava registada e a entrega de C418 só ocorreu depois.
Se o significado e a qualidade desses registos estiverem validados, C417 é a correspondência operacional compatível com a hora indicada. Ainda assim, há dois condutores autorizados. A conclusão útil não é «o titular cometeu a infração». É: «C417 é compatível com o momento indicado segundo os registos de entrega e receção; existem dois condutores autorizados; não há neste conjunto de dados evidência que determine qual conduzia».
Esta diferença evita dois saltos: escolher o contrato errado por usar previsões e escolher uma pessoa por confundir autorização com condução efetiva. Se as horas forem apenas momentos de introdução de dados, e não de entrega física, até a correspondência operacional precisa de revisão.
A conferência começa no significado dos campos
Antes de ligar um modelo de linguagem ao programa, é preciso perceber os dados. «Data de fecho» pode significar fecho administrativo. «Devolvido» pode ter sido marcado quando o funcionário retomou o trabalho no balcão. Uma reserva pode conservar a matrícula inicialmente atribuída apesar de o cliente ter saído com outra viatura.
A integração deve consultar a associação histórica entre viatura e contrato, não apenas a matrícula que aparece hoje na ficha. Deve distinguir uma previsão de um movimento efetivo e uma alteração posterior do registo original. Também tem de preservar a referência temporal da fonte, sem ajustar horas por suposição.
Se a notificação chegar digitalizada, a extração automática de matrícula, data e hora é uma proposta a confirmar no documento. Um carácter mal lido muda a pesquisa. Não faz sentido construir uma conferência rigorosa sobre uma matrícula que ninguém validou.
Quando faltam movimentos, o sistema deve mostrar a lacuna. Quando aparecem dois contratos sobrepostos, deve mostrar ambos. Escolher silenciosamente o resultado «mais provável» produz uma resposta limpa à custa de esconder precisamente aquilo que o operador precisava de saber.
O que a IA faz — e o que fica fora do seu alcance
A pergunta interna pode ser simples: «Que contratos e movimentos correspondem a esta matrícula, nesta data e hora, e que ambiguidades existem?» Por baixo, a pesquisa deve usar filtros e regras determinísticos, definidos para os sistemas do operador. Comparar intervalos de utilização não exige que um modelo invente uma interpretação.
A IA serve para tornar a consulta acessível e explicar os resultados. Deve conseguir indicar o contrato consultado, os movimentos relevantes e a origem de cada afirmação. Se disser que existe um condutor adicional, o utilizador autorizado deve conseguir verificar esse registo. Se não encontrar uma devolução efetiva, deve dizer que não a encontrou — não preencher a ausência com a hora prevista.
Read-only significa que as credenciais usadas nesta integração não permitem alterar contratos, acrescentar condutores ou corrigir movimentos. Também não existe, neste circuito, uma ação para enviar identificações à autoridade ou cobrar valores ao cliente. Uma correção necessária continua a ser tratada no sistema de origem, por uma pessoa com competência para a fazer.
Auditada significa manter um rasto verificável: quem consultou, quando, com que parâmetros, que registos e versões sustentaram a resposta e o que foi apresentado. Esse rasto deve evitar duplicar dados pessoais desnecessários. Uma resposta sem ligação à evidência é apenas texto bem escrito.
«O meu programa já pesquisa por matrícula»
Ótimo. Se a pesquisa existente apresenta o histórico correto, distingue previsões de movimentos e permite conferir rapidamente as exceções, talvez não precises de IA para este processo. Acrescentar uma conversa a uma pesquisa que já funciona não é, por si só, uma melhoria.
O trabalho à medida justifica-se quando a informação está repartida: contratos no programa de aluguer, receções noutra aplicação e documentos num arquivo separado. Nesse caso, o ganho a testar é reunir evidência e expor contradições sem obrigar o operador a reconstruir tudo manualmente.
A diferença também não está em prometer que «a IA responde a emails». Já existem assistentes que preparam respostas com fontes e revisão humana. Aqui, a exigência específica é outra: distinguir estados operacionais e pessoas com papéis diferentes antes de qualquer resposta. Um texto fluente não resolve um intervalo de utilização mal interpretado.
A integração pode começar por uma exportação autorizada ou por uma interface de consulta disponível no teu software. Não é preciso prometer um conector que ainda não foi validado, nem substituir o ERP para experimentar um circuito delimitado.
Os dados de identificação não precisam de circular com a pergunta
É possível começar a conferência mostrando referências de contrato e o número de condutores registados, sem expor logo todos os dados de identificação. O acesso aos elementos necessários para preparar a resposta deve ficar reservado a quem tem essa função.
Isto implica permissões por utilizador, limitação dos dados enviados ao modelo e uma política de conservação para documentos, respostas e registos de auditoria. O prestador técnico não precisa de acesso permanente e irrestrito ao arquivo de clientes. Usar IA fundada nos teus dados não significa copiar o arquivo inteiro para uma conversa.
Também é importante separar a proposta técnica da decisão operacional. O responsável pode concluir que precisa de consultar outro documento ou obter esclarecimentos. A ferramenta deve permitir verificar a evidência, não pressionar a pessoa a aceitar uma identificação sugerida.
Mede a conferência, não a aparência da resposta
Para testar este processo, podes selecionar, por exemplo, 20 notificações históricas já tratadas, com acesso controlado e dados minimizados. Este número é uma proposta de ensaio, não um resultado de cliente. Inclui casos simples, contratos com vários condutores, trocas de viatura, devoluções tardias e ausência de movimentos.
Mede o tempo até o responsável ter a evidência necessária para revisão, incluindo a verificação das fontes. Conta também as correspondências erradas e as ambiguidades que o sistema não assinalou. Uma resposta produzida depressa mas corrigida durante vários minutos não representa essa mesma poupança.
Define critérios antes do teste: nenhuma conclusão sobre o condutor efetivo baseada apenas no titular; todas as correspondências com origem verificável; todos os conflitos conhecidos do conjunto de ensaio assinalados. Se uma pesquisa convencional cumprir esses critérios com menos complexidade, usa a pesquisa convencional.
Ao rever os processos depois do verão e preparar os próximos meses, esta é uma unidade de trabalho concreta. Não é preciso presumir que todos os operadores açorianos ou madeirenses têm a mesma sazonalidade, o mesmo volume de notificações ou o mesmo programa de aluguer.
Começa por uma notificação, não por uma promessa de automação
Na Leiritech, a proposta é ligar um processo delimitado aos teus dados, com acesso só de leitura, auditoria e revisão humana. Trabalhas diretamente com a equipa pequena que escreve o código. Primeiro verifica-se o que o teu sistema permite consultar; depois testa-se se reunir e explicar essa informação melhora realmente o trabalho.
Esse projeto não precisa de ficar condicionado à aprovação de financiamento. Também não assenta na afirmação de que as regiões autónomas continuam genericamente excluídas da linha «IA nas PME»: a Portaria n.º 437-A/2025/1 alargou o enquadramento territorial a todas as regiões NUTS II nacionais. Isso não comprova uma candidatura aberta nem a elegibilidade de uma empresa concreta.
Propõe à Leiritech, pelo hello@leiritech.com, uma sessão de conferência de um caso anonimizado. O objetivo é mapear matrícula, tempos, contratos e fontes disponíveis — sem enviar documentos pessoais no primeiro contacto. No fim, a pergunta é verificável: conseguimos reunir melhor a evidência sem afirmar mais do que os registos demonstram?
