IA no atendimento do hotel: como usar sem violar a LGPD

Por que IA de atendimento é, antes de tudo, tratamento de dados pessoais

Um chatbot que responde dúvidas sobre reserva, um assistente que confirma horário de check-in pelo WhatsApp ou uma ferramenta que resume o histórico de um hóspede para a recepção têm algo em comum: para funcionar, precisam ler nome, telefone, número de reserva e, às vezes, preferências e histórico de estadia. Isso é tratamento de dados pessoais no sentido exato da LGPD, independentemente de a equipe pensar nessa ferramenta como "tecnologia de atendimento" e não como "sistema que guarda dados de hóspede".

O risco não está na IA em si. Está em adotar essas ferramentas pelo canal de marketing ou de operações, sem passar pela mesma avaliação de conformidade que se aplicaria à troca de um PMS ou de um gateway de pagamento. Quando isso acontece, o hotel frequentemente descobre meses depois que dados de hóspedes estão sendo processados (e às vezes armazenados) em um servidor de um fornecedor de IA sem contrato de operador, sem cláusula de segurança e sem prazo de retenção definido.

Onde a IA generativa entra hoje na operação hoteleira

• Chatbots de WhatsApp e Instagram: respondem perguntas frequentes, capturam dados de contato e, em muitos casos, já têm acesso de leitura ao PMS para confirmar disponibilidade e status de reserva.
• Assistentes de voz e centrais de atendimento com IA: transcrevem e às vezes gravam ligações de hóspedes para treinar respostas futuras. A gravação e a transcrição são dados pessoais, e o hóspede deve ser informado de que a ligação é gravada e para quê. Se a ferramenta usar características da voz para identificar o hóspede, isso passa a ser dado biométrico, que a LGPD trata como dado sensível (art. 5º, II).
• Ferramentas de resumo e triagem: usadas pela recepção ou reservas para resumir e-mails, mensagens ou o histórico de um hóspede antes de um atendimento.
• Personalização e recomendação: sugestões de upsell, pacotes ou comunicação de marketing baseadas em estadias anteriores e comportamento do hóspede.

Cada uma dessas categorias tem uma base legal e um nível de risco diferentes, mas todas compartilham o mesmo ponto cego: o dado do hóspede sai do PMS ou do canal de atendimento e passa a existir também dentro da infraestrutura do fornecedor de IA.

As bases legais que se aplicam

Execução de contrato: cobre a maior parte do atendimento operacional legítimo, como confirmar reserva, informar horário de check-in ou responder dúvidas sobre a estadia contratada. Não exige consentimento separado, mas exige que o uso da IA seja proporcional a essa finalidade.

Legítimo interesse: pode amparar o uso de IA para melhorar a qualidade do atendimento ou detectar fraude em reservas, desde que o hotel documente um teste de balanceamento (o benefício supera o risco ao titular) e informe isso de forma acessível, por exemplo na política de privacidade.

Consentimento: costuma ser a base adequada quando a finalidade foge da prestação do serviço de hospedagem, como usar o histórico de um hóspede para treinar um modelo próprio, gerar recomendações de marketing personalizadas entre marcas do grupo, ou compartilhar dados com um parceiro comercial. Consentimento genérico escondido em termos de uso extensos não atende ao padrão da LGPD; precisa ser específico para essa finalidade. Consentimento também não é a única saída: dependendo do caso, outra base do art. 7º pode ser mais adequada, e essa escolha deve ser documentada e validada pelo jurídico do hotel.

O fornecedor de IA costuma ser operador, não espectador

Ao conectar um chatbot, assistente de voz ou ferramenta de resumo a dados reais de hóspede, o hotel permanece como controlador e o fornecedor da ferramenta, em geral, atua como operador nos termos do art. 5º, VII, da LGPD. Se o fornecedor usar esses dados para finalidades próprias, como treinar os seus modelos, ele pode passar a atuar também como controlador nesse tratamento. Por isso o contrato precisa definir o papel de cada parte, e muitos contratos de SaaS de atendimento assinados sem revisão jurídica não fazem isso adequadamente. Na prática, o contrato deveria cobrir:

• Cláusula que proíbe o fornecedor de usar os dados do hotel para treinar modelos de uso geral, a menos que isso esteja explicitamente autorizado, e que diga por quanto tempo as conversas e os registros (logs) ficam guardados.
• Obrigação de notificar o hotel em prazo definido em caso de incidente de segurança na infraestrutura do fornecedor.
• Definição clara de onde os dados são processados e armazenados, e de quais subcontratados (como o provedor do modelo de linguagem usado por trás da ferramenta) têm acesso a eles. Quando os dados saem do Brasil, a transferência internacional precisa de um dos mecanismos previstos na LGPD e regulamentados pela ANPD na Resolução CD/ANPD nº 19/2024, como as cláusulas-padrão contratuais.
• Prazo de retenção e processo de exclusão de dados ao final do contrato ou mediante solicitação do titular.

Se o fornecedor de IA contratado sofrer um incidente, as obrigações de controlador continuam com o hotel: avaliar o incidente, decidir sobre a comunicação à ANPD e aos hóspedes afetados e responder a eles. O fornecedor também pode ser responsabilizado como operador, mas isso não tira o hotel da linha de frente. Um contrato bem redigido não evita o incidente, mas define as obrigações de segurança do fornecedor, o prazo em que ele precisa avisar o hotel e como coopera na resposta.

Dados que, como regra, não deveriam chegar a uma IA de atendimento de terceiros

Nem toda informação que passa pela recepção precisa (ou deveria) alimentar um chatbot ou assistente de IA. Como regra prática, mantenha fora do fluxo de qualquer ferramenta de IA de atendimento:

• Número completo de cartão de pagamento ou dados de checkout, mesmo quando o hóspede os digita espontaneamente numa conversa. Um chatbot que recebe ou guarda dados de cartão tende a trazer a ferramenta, e o fornecedor, para o escopo do PCI DSS; o caminho mais seguro é responder com um link de pagamento do gateway do hotel.
• Cópia ou número de documento de identidade além do necessário para o check-in presencial.
• Dados sensíveis nos termos da LGPD (saúde, origem racial, orientação sexual, entre outros), que raramente têm relação com o atendimento de hospedagem e não deveriam ser solicitados ou processados por uma IA de terceiros.

Isso vale tanto para o que o hóspede digita diretamente quanto para o que a ferramenta recupera automaticamente do PMS para montar uma resposta. Uma integração mal configurada que dá a um chatbot acesso de leitura ampla ao cadastro do hóspede, em vez de apenas aos campos necessários (nome, status da reserva, datas), é um erro frequente nesse tipo de projeto.

Ações, autenticação e escalonamento: os riscos próprios da IA

Além da LGPD, uma IA de atendimento traz riscos que um formulário ou um e-mail não trazem. Três deles merecem atenção antes de qualquer integração com o PMS ou o motor de reservas:

• Ações sem supervisão: uma IA com permissão para alterar, cancelar ou reembolsar reservas pode ser induzida a fazer isso por uma mensagem bem construída (o que a OWASP chama de prompt injection) ou errar a interpretação. Em geral, a IA pode consultar e preparar a ação, mas alterações, cancelamentos, reembolsos e pagamentos deveriam exigir confirmação humana ou do próprio hóspede por um canal verificado.
• Autenticação fraca: número de reserva, nome e telefone aparecem em e-mails de confirmação, em extratos de OTA e em capturas de tela. Servem para responder dúvidas gerais, mas não bastam para revelar dados da reserva ou alterá-la. Para operações sensíveis, use um código enviado ao e-mail ou telefone cadastrado.
• Escalonamento para humano: o hóspede precisa conseguir falar com uma pessoa quando a IA não resolve, e a conversa deve chegar à recepção ou a reservas com o histórico, para que ele não precise repetir tudo.

Um exemplo prático: um hóspede pergunta no WhatsApp o horário do check-in e se a reserva está confirmada. O chatbot responde usando apenas o status e as datas da reserva. Se o hóspede pede para mudar as datas, o chatbot confirma a identidade com um código enviado ao e-mail cadastrado e transfere o pedido para reservas com o histórico da conversa. Se o hóspede manda uma foto do cartão, a ferramenta não guarda a imagem e responde com o link de pagamento do gateway.

Um checklist prático antes de ativar qualquer IA de atendimento

1. Mapeie exatamente quais dados de hóspede a ferramenta vai ler, guardar e (se for o caso) usar para treinamento.
2. Defina a base legal para cada finalidade, e atualize a política de privacidade se a finalidade for nova.
3. Revise o contrato do fornecedor: cláusula de operador, notificação de incidente, local de processamento e retenção.
4. Limite o escopo de integração com o PMS ao mínimo necessário para a ferramenta funcionar.
5. Defina por escrito os limites: quais tópicos ou dados a IA nunca deve tratar, e para onde escalar quando isso acontecer.
6. Exija verificação de identidade e confirmação humana antes de qualquer alteração, cancelamento, reembolso ou pagamento.
7. Garanta que o hóspede consiga falar com uma pessoa, e que a conversa chegue à equipe com o histórico.
8. Defina o prazo de retenção das conversas e dos logs, e quem na equipe pode consultá-los.
9. Teste antes de publicar: tente fazer a IA revelar dados de outra reserva ou ignorar as próprias regras.

Próximos passos

Adotar IA no atendimento não exige abrir mão de conformidade, mas exige tratar essa decisão com o mesmo rigor de qualquer outro sistema que acessa dados de hóspede. Muitos problemas nesse tipo de projeto vêm de pular a etapa de mapeamento e contrato porque "é só um chatbot", exatamente o mesmo erro que já expôs hotéis em outras frentes, como pagamentos e redes de convidado.

Isso se conecta diretamente à adequação geral do hotel à LGPD e à governança de fornecedores de tecnologia como um todo. Nossa equipe pode avaliar uma ferramenta de IA antes da contratação, revisar o contrato do fornecedor e mapear o fluxo de dados entre o PMS e qualquer assistente de atendimento. Fale com a nossa equipe.

Fontes

• Lei nº 13.709/2018 (LGPD), arts. 5º, 7º, 11, 33 e 42, planalto.gov.br
• ANPD, Resolução CD/ANPD nº 19, de 23 de agosto de 2024 (Regulamento de Transferência Internacional de Dados e cláusulas-padrão contratuais), gov.br/anpd
• OWASP, Top 10 for LLM Applications 2025 (LLM01 Prompt Injection e LLM06 Excessive Agency), genai.owasp.org