Upload de documentos num chatbot de IA: verificação de ficheiros, proteção de dados e handoff

Um ícone de upload na janela de chat parece algo simples: selecionar o ficheiro, fazer a pergunta e obter a resposta. Do ponto de vista técnico e editorial, no entanto, começa aqui um processo próprio. Um documento pode conter dados pessoais, conteúdos ativos, estruturas de ficheiro manipuladas, digitalizações ilegíveis ou instruções que um modelo de linguagem não deve tratar como factos de confiança. É por isso que o upload de documentos num chatbot de IA precisa de limites claros antes da transmissão, de várias etapas de verificação posteriores e de uma solução compreensível caso algo não funcione.

O guia seguinte destina-se a equipas de website, suporte e produto. Não descreve a funcionalidade de um fabricante específico, mas sim um modelo ideal e robusto: as pessoas sabem o que é permitido antes de fazer o upload; o sistema separa a receção, a verificação de segurança e a avaliação do conteúdo; os erros mantêm-se claros; e os casos sensíveis são encaminhados de forma controlada para um ser humano.

O upload precisa de um objetivo claro

Não comece com uma lista exaustiva de formatos suportados, mas sim com poucas tarefas. O chatbot deve explicar os dados de uma fatura, resumir documentação técnica ou complementar um pedido de suporte com uma captura de ecrã? Para cada tarefa, deve ficar estabelecido quais os conteúdos necessários, que decisão o sistema pode tomar e quando a intervenção humana é obrigatória.

Esta limitação da finalidade evita que o upload se transforme num repositório geral de documentos. Também ajuda no design: um comprovativo de reclamação exige avisos e regras de retenção diferentes de uma descrição pública de produto para uma base de conhecimento. O guia existente sobre o treino com FAQs, documentos e conteúdos do website aborda a base de conhecimento curada; aqui, pelo contrário, trata-se de ficheiros submetidos pelos visitantes durante uma conversa em curso.

Tornar visíveis os tipos de ficheiro, tamanhos e quantidades permitidos

As pessoas devem ver as regras antes de a caixa de seleção de ficheiros se abrir: formatos permitidos, tamanho máximo, quantidade máxima e se são aceites ficheiros comprimidos ou protegidos por palavra-passe. Utilize uma lista de permissões (allowlist) que aceite apenas formatos estritamente necessários para o negócio. "Todos os documentos" não é um requisito útil.

O atributo HTML accept melhora a seleção no navegador, mas não é um controlo de segurança. A MDN destaca expressamente que os utilizadores podem frequentemente contornar a limitação de seleção, devendo a verificação ser feita no servidor. A interface pode, portanto, sugerir extensões adequadas, enquanto o servidor avalia de forma independente a extensão, o tipo MIME declarado, a assinatura real e a estrutura.

Não aceitar nomes de ficheiros e metadados sem verificação

O nome original pode conter carateres especiais, caminhos de diretório, cadeias de texto muito longas ou informações sensíveis. Para o armazenamento interno, o sistema deve atribuir um identificador aleatório próprio e tratar o nome visível apenas como informação de exibição higienizada. Da mesma forma, os metadados incorporados podem conter nomes, dados do dispositivo ou localizações. A necessidade destes dados deve decorrer da finalidade definida.

O File Upload Cheat Sheet da OWASP recomenda, entre outros, uma lista de permissões para extensões, verificação de tipo independente, nomes de ficheiros seguros, limites de tamanho, armazenamento fora do root da web e proteção contra uploads não autorizados. Nenhuma verificação isolada é suficiente; o ideal é uma cadeia de pequenos controlos rastreáveis.

Separar receção, verificação de segurança e avaliação

Um ficheiro recebido não deve ficar imediatamente disponível no chat. Um fluxo de trabalho robusto contempla pelo menos três estados: recebido, em verificação e liberado para avaliação. Durante a verificação, o ficheiro permanece numa área isolada. Só após aprovação no controlo é que o processo de extração obtém acesso. Devem ser evitados URLs públicos diretos ou caminhos de armazenamento previsíveis.

Verificação de malware e de estrutura

Consoante o risco, a análise de vírus ou sandbox, a verificação de assinatura e, em ficheiros Office ou PDF adequados, a reconstrução e desarmamento de conteúdos (CDR) devem fazer parte do processo. Ficheiros de arquivo, ficheiros aninhados e conteúdos com compressão invulgarmente alta precisam de limites específicos, pois podem consumir recursos ou atacar os parsers. Os scanners e as bibliotecas devem estar atualizados e configurados para que um erro de timeout ou de parsing não seja considerado uma aprovação.

A extração de texto é um estado de qualidade próprio

Um ficheiro seguro pode, ainda assim, ser inútil: uma digitalização desfocada, uma foto com reflexos, uma nota manuscrita ou um PDF sem camada de texto extraível. O sistema deve, portanto, reportar separadamente se o ficheiro foi recebido com segurança e se o conteúdo pôde ser lido com qualidade suficiente. Uma baixa qualidade de extração não deve ser mascarada por complementos inventados.

Formular erros de forma precisa e orientada para a ação

"Falha no upload" deixa em aberto o que fazer a seguir. É preferível apresentar mensagens distintas: formato não suportado, ficheiro demasiado grande, proteção por palavra-passe detetada, verificação de segurança falhada, texto ilegível ou processamento temporariamente indisponível. A mensagem não deve revelar detalhes internos do scanner ou da infraestrutura, mas deve oferecer uma alternativa de correção segura.

As WCAG 2.2 exigem a identificação e descrição em texto de erros de introdução detetados automaticamente. A explicação do Critério de Sucesso 3.3.1 Error Identification sublinha que a mera reexibição do formulário não é suficiente. Para o chat, isto significa: indicar o nome do ficheiro ou a posição do upload, explicar o erro em texto e oferecer uma opção concreta para substituir, remover ou encaminhar.

Comunicar o progresso de forma acessível

Ficheiros maiores geram tempos de espera. Uma barra visual, por si só, não ajuda todas as pessoas. As alterações de estado como "Upload em curso", "Verificação de segurança", "A ler conteúdo" e "Pronto" devem ser percetíveis de forma programática, sem alterar o foco do teclado sem solicitação. A explicação do W3C sobre o WCAG 4.1.3 Status Messages cita expressamente o progresso, o sucesso e os erros como informações de estado relevantes.

A ação de cancelar deve manter-se acessível. Após o cancelamento, deve ser visível se a transmissão foi efetivamente interrompida e se alguma cópia já recebida foi descartada. Em dispositivos móveis, o nome do ficheiro, o progresso e o botão de remoção devem estar dispostos de modo a não sobrepor a caixa de texto ou elementos de navegação importantes.

Explicar a proteção de dados antes do upload

O aviso deve responder antes da transmissão dos dados: Para que serve o ficheiro? Quem o pode ver? Quanto tempo permanece armazenado? O seu conteúdo é utilizado para melhorar algum modelo? Como pode o ficheiro ser removido? As políticas de privacidade gerais continuam a ser importantes, mas não substituem o aviso contextual fornecido diretamente no momento do upload.

O Artigo 5.º do Regulamento Geral sobre a Proteção de Dados inclui, entre outros, a limitação das finalidades, a minimização dos dados e a limitação da conservação. Na prática, isto significa: solicitar apenas documentos necessários, evitar páginas ou metadados desnecessários, definir um prazo de eliminação fundamentado e verificar tecnicamente a eliminação efetiva. Isto não constitui aconselhamento jurídico individual; as obrigações concretas devem ser avaliadas para cada caso de utilização.

Separar chats públicos de processos protegidos

Um chat público de website não é automaticamente o local adequado para contratos, documentos de identificação, dados de saúde ou comprovativos bancários. Em processos sensíveis, a conversa deve transitar para uma área autenticada ou para um canal seguro estabelecido. O artigo chatbot de IA público versus portal do cliente demonstra como a identidade e o acesso a dados devem ser separados.

Mesmo numa área com sessão iniciada, aplica-se o princípio do menor privilégio. Um agente de suporte pode precisar de visualizar um comprovativo, mas não necessita automaticamente de acesso permanente a todos os documentos enviados por uma conta. Os acessos, downloads e eliminações devem ser registados de forma rastreável, sem copiar desnecessariamente o conteúdo do documento para eventos de análise.

O conteúdo do documento continua a ser não confiável

Um ficheiro aprovado foi processado tecnicamente, mas o seu conteúdo ainda não é uma fonte de autoridade. Os documentos podem estar desatualizados, ser contraditórios ou ter sido intencionalmente manipulados. Podem também conter instruções destinadas a induzir o modelo a fugas de dados ou a contornar regras. Trate, portanto, o texto extraído como conteúdo não confiável (untrusted content), separe-o das regras do sistema e limite as ferramentas e acessos a dados.

O guia sobre prompt injection em chatbots de website explica este limite para RAG e ferramentas. Para os uploads, acresce ainda: as respostas devem referir partes identificáveis do documento, indicar incertezas e evitar preencher dados em falta em decisões críticas.

Human Handoff com um pacote de contexto reduzido

A transição para um humano é necessária quando a verificação de segurança falha repetidamente, a extração permanece não fiável, a identidade ou permissão são incertas ou a decisão técnica cabe a alguém fora do chatbot. Devem ser transmitidas apenas as informações que o ser humano precisa para dar continuidade: o pedido, o estado do upload, a referência segura do documento, a mensagem de erro concreta, os dados já confirmados e o passo seguinte pretendido.

O ficheiro não deve ser enviado adicionalmente por e-mail não protegido apenas porque o chatbot não o conseguiu ler. Um processo estruturado de human handoff preserva o contexto, a responsabilidade e as expectativas sem duplicar desnecessariamente conteúdos sensíveis.

Métricas com base em eventos, não no conteúdo dos documentos

Para a melhoria do produto, bastam frequentemente eventos estruturados: seleção iniciada, upload cancelado, tipo rejeitado, limite de tamanho atingido, verificação de segurança aprovada, extração insuficiente, transição selecionada e eliminação confirmada. Nomes de ficheiros, texto extraído e conteúdos pessoais não pertencem automaticamente às análises ou aos registos de erros.

Avalie em conjunto as métricas de sucesso e de proteção. Uma taxa de upload elevada não tem valor se muitas pessoas não entenderem qual o ficheiro esperado ou se documentos sensíveis forem parar ao chat público. Por isso, são também importantes a taxa de correção, o abandono após o aviso de privacidade, a percentagem de ficheiros ilegíveis, o tempo até à mensagem de erro e a continuidade com sucesso após o handoff.

Lista de verificação antes do lançamento

• Existe uma finalidade clara e um tipo de documento permitido definidos para cada caso de upload?
• O formato, tamanho, quantidade, proteção por palavra-passe e retenção estão visíveis antes da seleção?
• O servidor verifica a extensão, o tipo MIME, a assinatura, a estrutura e os limites de tamanho independentemente do navegador?
• A quarentena, verificação de malware, extração e aprovação estão implementadas como estados separados?
• As pessoas recebem mensagens de progresso e de erro precisas e acessíveis?
• Os processos sensíveis são transferidos para um canal autenticado ou com apoio humano?
• O prazo de eliminação, acesso, registo de logs e eliminação confirmada foram testados na prática?
• O chatbot trata o texto extraído como não confiável e cita trechos rastreáveis?
• As ferramentas de análise contêm apenas os eventos necessários em vez de nomes de ficheiros ou conteúdos de documentos?
• O handoff foi testado com casos de erro reais no computador e no telemóvel?

Conclusão: O upload seguro começa antes do ficheiro

Um bom upload de documentos estabelece limites visíveis antes da transmissão de dados. Depois, separa a receção técnica, a verificação de segurança, a qualidade do conteúdo e a decisão operacional. Desta forma, um chatbot de IA pode utilizar documentos como um contexto de conversa útil sem confiar precipitadamente em cada byte recebido ou instrução extraída.

Quem pretende criar um chatbot para website e integrar estes fluxos de trabalho numa arquitetura global e fiável pode consultar as funcionalidades do ChatReact. Planeie o upload como um processo de serviço controlado — com consentimento claro, estado compreensível e um caminho seguro até ao ser humano.

Fontes

• OWASP Cheat Sheet Series: File Upload
• MDN: accept HTML attribute
• W3C WAI: Understanding Status Messages
• W3C WAI: Understanding Error Identification
• EUR-Lex: Regulamento (UE) 2016/679