A lacuna de confiança

Algures na costa portuguesa, uma anfitriã de alojamento local abre o email às seis da manhã. Entrou uma reserva durante a noite. O hóspede é de Lyon e chega daqui a três dias. Antes de ele chegar, ela tem seis coisas para fazer. A que vai correr mal é o passaporte.

A lei portuguesa obriga-a a comunicar a identidade do hóspede às autoridades nas vinte e quatro horas seguintes à chegada, verificada com base num passaporte ou documento equivalente. A lei existe há mais de uma década. A coima por falhar uma comunicação é avultada. A maioria dos anfitriões que ela conhece nunca foi fiscalizada.

Uns dias antes de o hóspede chegar, ela envia uma mensagem educada pelo chat da plataforma de reservas. Olá, estamos muito contentes por o receber. Precisamos de lhe pedir alguns dados para entregar às autoridades. Somos obrigados por lei. Poderia enviar uma fotografia do seu passaporte para eu o poder registar? O inglês dela é hesitante. A mensagem chega à aplicação do hóspede traduzida por um algoritmo, onde soa mais fria do que ela pretendia.

Oito em cada dez vezes, o hóspede recusa.

As razões variam. Não quer enviar uma imagem do passaporte pelo chat de uma plataforma de reservas. Não sabe o que é o SIBA, nem se é real. Já ouviu histórias de roubo de identidade e desconfia por princípio. Em vez disso, oferece-se para enviar os números, escritos no chat. Ela aceita o que consegue. Escreve os números no portal do SIBA. Não os verifica com base num documento que não viu. Submete.

Ela sabe que não é isto que a lei exige. Também sabe que ninguém que conhece alguma vez foi fiscalizado. Toda a gente faz assim. O regime de cumprimento, tal como existe de facto em 2026, é papelada que assenta numa confiança que ela não consegue verificar de forma independente.

Este ensaio é sobre porque é que isto acontece, e que tipo de infraestrutura é necessária para que deixe de acontecer.

O que a lei exige

O Decreto-Lei n.º 128/2014, com as suas alterações posteriores, obriga quem explora alojamento de curta duração a comunicar a identidade de cada hóspede estrangeiro à autoridade competente dentro de uma janela curta após a chegada. O mecanismo é um portal web onde o anfitrião introduz o nome do hóspede, o número do documento, a data de nascimento, a nacionalidade, o país de emissão e as datas da estada. O portal não guarda nada sobre o processo de verificação do anfitrião. Aceita o que o anfitrião escrever.

Existem obrigações equivalentes por toda a UE. Espanha tem o Registro Único de Huéspedes. França tem a fiche individuelle de police. Itália tem o portal Alloggiati Web. Os Países Baixos têm o nachtregister. A Grécia tem o Special Register. Os pormenores diferem. A forma é a mesma: os anfitriões de alojamento de curta duração têm de registar cada hóspede, o registo é feito independentemente da plataforma de reservas, e o passo de verificação existe na lei mas não é imposto pela arquitetura.

O Acervo de Schengen sustenta isto. O regime é anterior ao alojamento de curta duração em grande escala. Foi concebido para hotéis, onde um rececionista de uniforme pega no passaporte, passa-o por um scanner e devolve-o. O quadro legal pressupunha um passo de verificação presencial. O alojamento de curta duração não inventou a ausência desse passo. Descobriu-a, ao esticar o regime para um formato de utilização para o qual nunca foi concebido.

Uma nota sobre rigor: o texto acima é o resumo de quem não é jurista. O texto aplicável em Portugal é o Decreto-Lei n.º 128/2014, de 29 de agosto de 2014, na sua redação atual (texto consolidado disponível em diariodarepublica.pt); a comunicação de hóspedes é feita através do sistema SIBA de boletins de alojamento, que desde a extinção do SEF em 2023 passou a ser administrado pelas autoridades. Os equivalentes da UE são identificados pelas designações comuns e não pelas citações completas; os instrumentos concretos variam consoante a jurisdição e agradecemos correções de juristas qualificados. Está em preparação um documento de notas de conformidade mais completo.

O que os anfitriões realmente fazem

A taxa de recusa de 80% não é um inquérito. Não existe uma estatística pública para tal, e é pouco provável que alguma vez exista. Nenhum anfitrião pode admitir publicamente com que frequência o passo de verificação falha sem se expor a uma responsabilidade regulatória que não merece e a represálias da plataforma que não pode suportar. O padrão vive nas conversas que os anfitriões têm entre si em privado, nos encolheres de ombros nos encontros locais, nas mensagens trocadas com os contabilistas que tratam discretamente das suas contas. Sabemos disto porque os anfitriões que o partilharam connosco confiam que aquilo que disseram não os colocaria em risco. O número é uma afirmação de ordem de grandeza, ancorada nessas trocas privadas. O que importa é a ordem de grandeza. O número exato é incognoscível até que as plataformas ou os reguladores escolham torná-lo conhecido.

Da pequena fração que não recusa de imediato, a maioria envia os dados de identidade como texto escrito no chat da plataforma: um nome, um número de documento, uma data de nascimento. Alguns enviam uma fotografia. Os anfitriões que insistem na fotografia arriscam-se a que o hóspede cancele a reserva. Os anfitriões que não insistem na fotografia aceitam o texto e seguem em frente.

Os anfitriões sabem que aquilo que estão a fazer não é o passo de verificação que a lei pressupõe. Fazem-no na mesma. Os mecanismos de reclamação das plataformas criam um efeito inibidor: um hóspede que se sinta demasiado escrutinado pode deixar uma má avaliação, apresentar uma reclamação, pedir um reembolso, ou as três coisas. O sustento do anfitrião fica à mercê desses mecanismos. O poder de fiscalização do regulador é teórico. O poder de punição da plataforma é imediato.

Isto não é negligência. É uma resposta racional a um sistema cujos incentivos estão desalinhados. O anfitrião foi deixado a navegar, sozinho, uma contradição que ninguém quis criar mas que toda a gente no sistema tem razões para manter.

Como as plataformas ampliam a lacuna

As plataformas de reservas não resolvem este problema. Também não se mantêm neutras à margem dele. Tornam-no ativamente mais difícil de resolver, em três frentes.

Penalizam as comunicações fora da plataforma. Os anfitriões que tentam levar os hóspedes para o WhatsApp, onde é mais provável que partilhem uma imagem, enfrentam perda de posicionamento e penalizações no anúncio. As plataformas impõem a comunicação dentro da plataforma como prioridade de negócio. O contorno de conformidade que a comunidade de anfitriões sabe que ajudaria é, justamente, o contorno que as plataformas proíbem.

Penalizam ligações externas no chat. Os anfitriões que tentam partilhar uma ligação para uma página de carregamento controlada pelo anfitrião, onde um hóspede poderia confiar mais na arquitetura do que no chat da plataforma, veem essas ligações classificadas como desvio de reserva para fora da plataforma. A ligação é assinalada. O anfitrião é avisado. Infrações repetidas arriscam a remoção do anúncio.

O seu mecanismo de reclamação pune os anfitriões que tentam verificar presencialmente. Um anfitrião que recebe um hóspede à porta e pede para ver um passaporte antes de entregar as chaves cria um momento de atrito. O hóspede pode reclamar à plataforma, pedir um reembolso ou escrever uma má avaliação. Os anfitriões que dependem do posicionamento da plataforma, que são a maioria, não se podem dar ao luxo do atrito. O passo de verificação que a lei pressupõe acontecer à porta é o passo de verificação que os incentivos económicos da plataforma desencorajam.

As plataformas estão presas numa contradição. A imposição da comunicação interna protege o seu negócio principal. A sua crescente exposição regulatória na UE empurra-as para uma verificação de identidade do hóspede mais forte ao nível da plataforma. As obrigações regulatórias dos seus anfitriões ficam entre as duas. Estão cientes desta contradição. Ainda não a resolveram por si próprias, porque resolvê-la exigiria enfraquecer o aprisionamento das comunicações na plataforma ou tornar-se um responsável pelo tratamento de dados regulado para dados de identidade de categoria especial. Ambas são posições que evitaram ativamente durante anos.

Porque é que nenhum agente centralizado pode resolver isto

A resposta intuitiva é as plataformas deviam simplesmente construir isto. As plataformas não conseguem construir isto, por uma razão que é mais estrutural do que política.

A recusa dos hóspedes em enviar imagens do passaporte não é arbitrária. É uma resposta à centralização do canal pelo qual lhes pedem que as enviem. O hóspede não confia os seus dados de identidade de categoria especial à plataforma de reservas. Um fornecedor de SaaS alojado a resolver o problema em nome da plataforma herdaria exatamente a mesma posição de confiança, porque o hóspede perceberia corretamente o fornecedor de SaaS como mais uma parte centralizada por onde os dados têm de passar. Os dados não se tornaram mais privados; apenas mudaram de empresa que os detém.

O problema não é uma funcionalidade em falta. O problema é que a arquitetura de todas as partes existentes, plataforma, fornecedor, SaaS alojado, é incompatível com a forma de confiança que o hóspede está a pedir. A centralização é o substrato onde o problema cresce. Qualquer solução que corra sobre o mesmo substrato não pode dar um fruto diferente.

A arquitetura capaz de fechar esta lacuna tem quatro propriedades que não são opcionais:

1. A imagem do hóspede é carregada para um sistema que o anfitrião opera, não para o armazenamento da plataforma, nem para o armazenamento de um fornecedor. Nenhum responsável pelo tratamento de dados de terceiros se interpõe entre o hóspede e o sistema do anfitrião. O hóspede pode ser informado disto e a arquitetura demonstra-o.
2. A inferência corre com a própria chave de API do anfitrião, não a do operador. Cada chamada de inferência envia uma única imagem para o ponto de acesso comercial da Anthropic, recebe uma única resposta e nada mais; aplicam-se os compromissos comerciais da Anthropic (sem treino com os dados de API dos clientes; Retenção de Dados Zero disponível para contas elegíveis). O núcleo de raciocínio nunca vê uma base de dados centralizada de imagens de identidade. O sistema do anfitrião nunca tem mais do que a imagem de um hóspede de cada vez, e descarta-a depois de a submissão regulatória ser confirmada.
3. O registo de auditoria é encadeado por hash e pertence ao anfitrião. Não é guardado no servidor de um fornecedor. Não é guardado na plataforma. O anfitrião pode produzi-lo a pedido para um regulador, uma autoridade tributária ou um titular dos dados curioso, sem a autorização de ninguém.
4. A telemetria que regressa a quem opera o sistema é redigida por construção. O operador vê tipos de eventos, contagens e hashes. Nunca vê nomes de hóspedes, números de passaporte, moradas, nem qualquer elemento dos dados de categoria especial. A arquitetura prova-o, em vez de o prometer.

Isto não é uma lista de afirmações de marketing. É a especificação mínima real de uma arquitetura em que o hóspede confiará o suficiente para colaborar. Qualquer coisa a que falte uma destas propriedades deixa o hóspede com a mesma objeção que o levou a recusar o chat da plataforma, logo à partida. Um tratamento mais aprofundado das razões por que cada propriedade é necessária, com uma análise caso a caso de por que razão as alternativas mais fracas (SaaS centralizado com cifragem forte, residência dos dados na UE, chaves geridas pelo cliente) continuam a falhar o teste de confiança, está em preparação na documentação de arquitetura do projeto.

O corolário é que a arquitetura que a lacuna exige é uma que as partes com a distribuição para a implementar em grande escala não conseguem construir, e as partes que a conseguem construir (pequenas, independentes, estruturalmente local-first) não têm a distribuição. Esta é a forma clássica de uma lacuna de mercado que se agrava quanto mais tempo permanece por resolver.

A arquitetura admite também dois caminhos de reforço que o desenho já antecipa. A extração híbrida, com OCR no próprio equipamento do anfitrião e leitura da zona de leitura automática do documento, encaminhando apenas os campos de texto extraídos para o Claude, impede que os bytes da imagem cheguem sequer a sair do hardware do anfitrião. A inferência em computação na nuvem controlada pelo cliente, através do Amazon Bedrock ou do Google Vertex, mantém os dados dentro da própria infraestrutura de nuvem do cliente na UE. Nenhum dos dois é necessário para a primeira instalação; ambos estão ao alcance a partir do desenho da v1, sem ter de a refazer. O teto de privacidade da arquitetura é mais alto do que aquilo que a versão v1 consome.

O que isto implica de forma mais ampla

O caso do alojamento de curta duração português é uma instância local de um padrão à escala do continente. Todas as jurisdições da UE têm leis análogas de registo de hóspedes. Todas têm a mesma forma de lacuna de confiança no canal entre plataformas, anfitriões e hóspedes. A população estimada de operadores afetados não é na ordem dos milhares. É de milhões, no setor da hotelaria, do alojamento de férias, das pensões, dos albergues e das categorias de alojamento regulado adjacentes.

As implicações vão mais longe. Sempre que uma PME regulada da UE é obrigada a recolher, verificar e comunicar dados de categoria especial em nome de um regulador, e sempre que o canal por onde esses dados têm de viajar é mediado por uma plataforma cujos pressupostos arquitetónicos são incompatíveis com a confiança que os dados exigem, existe a mesma lacuna. E as mesmas duas alavancas fecham-na: um canal em que a contraparte possa confiar, e um pedido redigido com cuidado, na sua própria língua, que responda à sua verdadeira preocupação. O alojamento de férias é o caso mais visível. Não é o único caso.

Esta é também uma história sobre como a IA pode ser implementada de forma responsável num ambiente de produção regulado. O núcleo de raciocínio que faz a leitura efetiva do documento, o rascunho multilingue, a geração do registo de auditoria e o apoio à decisão é um grande modelo de linguagem de fronteira. Mal feito, uma IA assim torna-se um fornecedor centralizado a consumir dados de categoria especial em grande escala, criando a sua própria versão da lacuna de confiança. Bem feito, corre num formato de utilização em que o operador está estruturalmente fora do caminho dos dados de inferência, o cliente controla diretamente a relação com a IA, e a revisão humana valida cada ação que toca o regulador. O mesmo modelo, num formato de utilização diferente, produz resultados opostos para a confiança do hóspede e para o cumprimento regulatório. As duas metades importam: a capacidade que o modelo traz, e a postura arquitetónica que permite que essa capacidade chegue ao utilizador em segurança. Nenhuma delas, sozinha, é suficiente.

O que estamos a construir

Somos um pequeno grupo no início deste trabalho. O nicho do alojamento de férias é por onde estamos a começar, porque trabalhamos diretamente com uma anfitriã portuguesa cujo negócio é exatamente a forma que este ensaio descreve, e porque a arquitetura que acreditamos ser necessária para o mercado mais amplo das PME reguladas da UE pode ser comprovada aqui, primeiro, em pequena escala.

A plataforma chama-se Obra. É construída sobre o Claude. Corre na infraestrutura do anfitrião, invocando o Claude com a própria chave de API da Anthropic do anfitrião. Conduz a recolha da identidade do hóspede através de um canal estruturalmente fiável que o anfitrião controla. Produz um registo de auditoria encadeado por hash que pertence ao anfitrião. Associa cada ação que toca o regulador a um passo de verificação humana que o anfitrião aprova, antes de a ação correr. Está a ser lançada como serviço gerido, com as competências específicas do setor lançadas em código aberto sob a licença Apache 2.0.

Há aqui uma segunda alavanca, para além da arquitetura. O pedido do passaporte falha em parte por causa do canal e em parte por causa do próprio pedido. Como é a Obra que redige o pedido, pode escrevê-lo como o faria uma anfitriã cuidadosa e fluente: na língua do hóspede, na voz da anfitriã, explicando com clareza por que razão a lei o exige e o que acontece à imagem depois. E como o mesmo núcleo de raciocínio lê as respostas do hóspede, consegue reconhecer a preocupação concreta por detrás de uma hesitação, uma sigla desconhecida, o receio de roubo de identidade, a desconfiança do chat da plataforma, e redigir uma resposta a essa preocupação diretamente, em vez de repetir um guião, para a anfitriã enviar. A arquitetura remove a objeção estrutural do hóspede. A redação remove o atrito humano. Um pedido caloroso, claro e atento, por um canal em que o hóspede pode confiar, tem muito mais probabilidade de ser aceite do que um pedido frio por um canal em que não confia. Quanto mais, tencionamos medi-lo; de qualquer forma a resposta é útil, porque aquilo que o pedido não conseguir ganhar, a arquitetura tem na mesma de apanhar.

Não estamos a tentar tornar-nos uma plataforma de reservas. Não estamos a tentar competir por hóspedes. Estamos a tentar fazer com que o passo de conformidade que a lei já exige funcione de facto, dentro da realidade dos canais em que os anfitriões já vivem.

O pacote de referência vertical em código aberto está em github.com/get-obra/claude-for-portuguese-al-hosts. A arquitetura está documentada; dois dos ficheiros de competências já lá estão. Os restantes chegam nas próximas semanas. O ciclo central já corre nos nossos próprios testes: um formulário de registo de hóspedes preenchido automaticamente, campo a campo, e uma mensagem aprovada pelo anfitrião enviada a partir da conta do próprio anfitrião, com cada passo registado na cadeia de auditoria e a submissão final ao regulador deixada para o anfitrião. A primeira instalação arranca com a anfitriã portuguesa que é o tema de grande parte deste ensaio, neste verão.

O trabalho é também uma hipótese sobre o que é, afinal, uma implementação responsável de IA nos setores regulados da UE. Acreditamos que as propriedades arquitetónicas que fecham a lacuna de confiança no alojamento de curta duração são as mesmas propriedades que fecham as lacunas de confiança análogas no universo mais amplo das PME reguladas da UE: contabilistas sob obrigações de minimização de dados, gestores de propriedades sob a lei de privacidade dos inquilinos, pequenos prestadores de cuidados de saúde sob regimes equivalentes ao RGPD na saúde, escritórios de advogados sob o sigilo profissional. O nicho é um setor. A aposta é a arquitetura.

Uma nota sobre o que este ensaio não é

Isto não é um argumento de venda. Este ensaio existe porque o problema que descreve é real e estruturante para a implementação de IA nos setores regulados europeus, e porque acreditamos que a análise é mais útil como leitura pública do que como uma apresentação de slides para dez reuniões.

Também não é uma queixa contra as plataformas de reservas. As plataformas são grandes empresas a operar num ambiente regulatório complexo, com restrições que nós não enfrentamos. Acreditamos que existe um caminho com forma de parceria em que a sua postura de conformidade melhora e a vida dos seus anfitriões fica mais fácil, fornecendo nós a camada de infraestrutura que elas, com razão, escolheram não construir internamente. Esperamos que essa conversa aconteça numa data futura, que depende de trabalho que ainda não fizemos.

É, sobretudo, o tipo de ensaio que teríamos gostado de ler há seis meses, quando começámos a construir. Se lhe for útil, ou se vir algo em que nos enganámos, um email para team@get-obra.com encontra-nos.