A lei por aplicar

Num resort algures na costa portuguesa, no verão passado, o rececionista de turno escreve um número de passaporte no portal de cumprimento. Não viu o documento. O número veio de uma ficha de hóspede que um colega escreveu à mão a partir de uma fotografia que ninguém consegue encontrar. Às vezes escreve números que ninguém lhe entregou, porque a reserva entrou tarde e o sistema precisa de qualquer coisa. O portal aceita o que ele submeter. O sistema de gestão de propriedade que o resort paga, com uma anuidade a sério, submete o registo a tempo, todas as vezes. A caixa verde no painel diz que está em conformidade. Ninguém no resort acredita na caixa verde. Ninguém no regulador alguma vez ligou. Toda a gente neste arranjo está aqui há anos.

Este resort não é um operador pequeno. Pela trilha de auditoria do sistema, todas as reservas estiveram em conformidade em todas as comunicações, durante anos. Pela cláusula de verificação da lei, quase nenhuma destas comunicações está, de facto, em conformidade.

Este ensaio é sobre como é que um mercado chega a este estado e se mantém aqui. É sobre o mecanismo que torna a lacuna invisível para as pessoas que estão mais expostas a ela, a economia que impede que alguém seja pago para a fechar, e a arquitetura que a fecharia de facto, se alguém a construísse. E é sobre por que é que estamos a construir essa arquitetura antes de o mercado saber que precisa dela.

O que o mercado está a pagar

Em Portugal, anfitriões de alojamento local e resorts pagam por software que promete cumprimento da lei nacional de comunicação de hóspedes. O mercado divide-se em três camadas. Há ferramentas especialistas em SIBA que ligam diretamente à API da autoridade e submetem o boletim em nome do anfitrião. Há sistemas de gestão de propriedade que integram uma dessas especialistas no seu próprio fluxo de chegada. Há produtos adjacentes, fechaduras inteligentes e gestores de canais, cujo marketing toca no cumprimento mas que não fazem, eles próprios, a submissão.

A primeira camada é sobre a qual este ensaio incide mais, porque a submissão é a parte do encadeamento que funciona. O boletim chega ao regulador. O prazo é cumprido. A caixa verde no painel está honestamente verde no que diz respeito ao passo que representa. Os fornecedores desta camada são produtos bem feitos com preços acessíveis ao consumidor (a Chekin desde cerca de quatro euros por propriedade por mês, a ChargeAutomation à volta de cinco dólares mais uma taxa de plataforma, a Sincro desde gratuito até quatro euros, a SIBA GO num modelo de pacotes de créditos, outras na mesma banda). O mercado precificou a submissão como uma comodidade rotineira, e os fornecedores entregam o que esse preço permite.

O que varia entre camadas, e o que o marketing torna legível a quem o ler, é o que acontece entre o momento em que o hóspede abre a ligação e o momento em que o boletim é submetido. A página de verificação de identidade da Chekin é a mais precisa que a categoria oferece: OCR mais soma de controlo da zona de leitura mecânica, com os dois comparados entre si para apanhar documentos adulterados; uma correspondência biométrica entre selfie e a fotografia do documento; estímulos de vivacidade ativa; deteção de deepfake e de máscara; com a frase final explícita, "From document capture to verified guest — no manual review needed". É uma oferta de verificação completa e a sério, e é a mais forte que o mercado tem para mostrar. Outros especialistas escolhem partes do conjunto: a CheckinScan reivindica a leitura da MRZ mas não a biometria, a SEFScan reivindica OCR com avisos de nova tentativa mas não verifica a MRZ, a ChargeAutomation reivindica verificação biométrica de identidade mas é omissa quanto ao resto, e a Avantio comercializa verificação biométrica através da sua integração com a Chekin. E depois há uma lista mais longa (Sincro, SIBA GO, fluxo SIBA da Homeit, módulo de cumprimento da Your.Rentals, Ynnov, check-in nativo da Smoobu, módulo de registo nativo da Lodgify e formulário de check-in nativo da Hostaway) onde as páginas de produto que consultámos descrevem recolha e submissão de dados, mas nenhum passo de verificação.

A própria documentação de apoio da Hostaway coloca isto nos termos mais concisos que alguém na categoria está disposto a registar por escrito: "Hostaway does not check the ID of the Guest to make sure that it is not a fake." Um grande sistema global de gestão de propriedade, a declarar abertamente na sua própria documentação que o portal de hóspede que disponibiliza não faz verificação de identidade.

Portanto, a pergunta não é se a verificação existe neste mercado. Existe. A pergunta é o que o mercado está a pagar. Os escalões de verificação, onde existem, ficam no topo da escada de preços. O conjunto completo de verificação de identidade da Chekin é um suplemento Premium ou Enterprise, acima do escalão Básico que a maioria dos operadores compra. A maioria dos operadores não compra o escalão de verificação, porque o regulador não pede o escalão de verificação. O regulador pede a submissão. A submissão é o que o escalão mais barato cobre. O prazo é cumprido, a caixa fica verde e o anfitrião recebe o recibo da submissão no seu correio.

É este o padrão estruturante. O mercado não está privado de opções de verificação. O mercado escolhe, pelo que compra, pagar apenas pela submissão. A oferta de verificação existe para os operadores que decidem que precisam dela. Os operadores ainda não decidem que precisam dela, porque ninguém lhes está a perguntar se a fizeram. O mercado está, conscientemente, a pagar por um produto diferente daquele que a lei exige, e os fornecedores estão, conscientemente, a construir o produto pelo qual o mercado está a pagar.

Como cada um da cadeia tem o seu papel

Um mercado com esta forma não se sustenta pela má-fé de ninguém. Sustenta-se pelo comportamento racional de toda a gente nele.

O anfitrião é racional. Na maior parte das vezes, o hóspede recusa enviar uma fotografia do passaporte pelo chat da plataforma de reservas, pelas razões descritas no primeiro ensaio. O anfitrião aceita o que consegue, escreve os números no portal e submete. Sabe que não é isto que a lei exige. Também sabe que ninguém que conhece alguma vez foi fiscalizado, e que o mecanismo de reclamações da plataforma de reservas o pune por verificar presencialmente com mais fiabilidade do que o regulador o pune por não verificar de todo. Está a responder aos incentivos que existem.

O fornecedor é racional. Construir um produto de verificação quando o mercado está a pagar por um produto de submissão não é uma estratégia que um fornecedor consiga sustentar no escalão base. Os fornecedores que oferecem verificação oferecem-na como suplemento acima do escalão de submissão, porque é aí que está a disposição para pagar. O fornecedor que tenta vender verificação como base é desfeito pelo fornecedor que vende submissão como base. O mercado escolheu, pelo que compra, que a submissão é o produto. O fornecedor constrói o que o mercado compra, e coloca a verificação por cima, num escalão para os operadores que decidem que precisam dela.

A plataforma é racional, no sentido descrito no primeiro ensaio. A plataforma protege as comunicações dentro da plataforma e penaliza os canais paralelos pelos quais um anfitrião conseguiria verificar um documento. Os incentivos da plataforma não se alteram pela obrigação regulatória do anfitrião.

O regulador é racional. Fiscalizar uma população com dezenas de milhares de pequenos operadores num setor fragmentado, com ferramentas e orçamento limitados, é estruturalmente pouco atrativo. As ações de fiscalização concentram-se onde são economicamente racionais, nos maiores operadores com as violações mais visíveis. A cauda longa é matematicamente invisível.

O hóspede é racional. Nunca lhe explicaram por que é que lhe estão a fazer a pergunta. Já ouviu histórias de roubo de identidade. Não está errado em ser cauteloso com uma imagem de passaporte enviada pelo chat de uma plataforma de reservas a um estranho que ainda não conheceu.

O resultado de todo este comportamento racional é um regime de cumprimento que assenta em papelada que a lei não reconheceria como cumprimento. A expressão para isto, nos círculos de segurança, é theater, que não é bem a palavra certa aqui, porque ninguém no resort está a representar. Estão a preencher a caixa porque a caixa é o que o sistema pede e o sistema é o que constitui o seu cumprimento. A representação é o próprio sistema, perante uma plateia que ainda não chegou.

O endereço que nunca muda

Há mais uma camada que torna a lacuna invisível, e foi a que mais nos surpreendeu, quando um operador português a articulou pela primeira vez nas suas próprias palavras.

Se perguntassem a um anfitrião cujo nome consta na queixa regulatória no dia em que o seu sistema de gestão de propriedade deixa fugir cinquenta mil passaportes, quatro em cada cinco apontariam o sistema. Estariam enganados. Ao abrigo da lei de proteção de dados da UE, o anfitrião é, em quase todos os casos, o responsável pelo tratamento. O sistema é, na postura contratual habitual, um subcontratante. O contrato entre eles muda dinheiro de mãos em certos tipos de falha. Não muda o endereço regulatório. O anfitrião está a carregar a responsabilidade pelo comportamento do sistema desde que o usa, e não a consegue ver, porque ninguém no seu mundo alguma vez precisou de olhar para isso.

Este é o mecanismo estruturante por detrás do teatro de cumprimento. Os anfitriões delegaram, nas suas próprias cabeças, a função de cumprimento ao sistema. O regime jurídico não delegou nada. O regime considera o anfitrião como a parte responsável pelos dados do hóspede, pela verificação da identidade do hóspede, pelo fundamento legal do tratamento e pela eventual eliminação do documento. O sistema que o anfitrião usa é, aos olhos do regulador, uma ferramenta que o anfitrião escolheu, uma ferramenta cujas falhas também são falhas do anfitrião.

Não vimos isto declarado, nesta forma, em qualquer material de marketing de um fornecedor da categoria. Não vimos as plataformas dizê-lo. Não vimos isto declarado nas orientações públicas do regulador para anfitriões. Vimo-lo entendido, depois de o explicarmos, por todos os anfitriões com quem falámos. A reação foi a mesma de todas as vezes: uma pausa longa, e depois uma pergunta sobre o que diz, afinal, o contrato com o fornecedor. Os contratos dizem o que os contratos costumam dizer. Contêm indemnizações e limitações de responsabilidade que não foram testadas num tribunal português, porque nenhum tribunal português foi ainda chamado a fazê-lo.

O resultado não é que a lei esteja errada. O resultado é que há um ponto-cego estrutural de responsabilidade pousado em cima de cada operador desta categoria, e o ponto-cego é a razão precisa pela qual o operador não se sente compelido a comprar verificação. Não acreditam que precisam dela, porque não acreditam que o endereço seja deles.

Uma nota sobre rigor: este é o resumo de quem não é jurista, do quadro dos artigos 4.º, n.os 7 e 8, e 28.º do RGPD. A repartição concreta entre um anfitrião e um sistema de gestão de propriedade depende do contrato, do padrão real de tratamento e da interpretação da autoridade de controlo competente. Existe jurisprudência relevante sobre corresponsabilidade pelo tratamento (Fashion ID, Wirtschaftsakademie), em que uma ferramenta determina finalidades ou meios de uma forma que a torna corresponsável. O ponto geral, de que um anfitrião que usa um fornecedor permanece responsável pelo tratamento aos olhos do regime, não é contestado. Agradecemos correções de juristas qualificados.

Por que é que o mercado não paga

Há um nome, no desenho de mercados, para o tipo de mercado que este ensaio descreve. Chama-se mercado regulado latente sem evento desencadeador. A obrigação legal existe. O risco do incumprimento é real. A urgência sentida é zero. Toda a gente está em incumprimento. Ninguém é punido. Ninguém compra.

O RGPD pareceu-se com isto entre 2016 e cerca de 2019. Os fornecedores que construíram infraestrutura séria de conformidade com o RGPD em 2017 tiveram um ano fino. As primeiras grandes coimas cristalizaram o mercado nos doze meses seguintes, e os integradores que estavam prontos herdaram-no. O PCI-DSS pareceu-se com isto nos seus primeiros anos, antes de as redes de cartões começarem a impor a norma em larga escala. A conformidade com acessibilidade nos Estados Unidos pareceu-se com isto até que a onda de processos ADA chegou ao segmento das pequenas empresas. O padrão tem sempre a mesma forma: lei real, fiscalização adormecida, sem mercado, até que um acontecimento o vira. Depois da viragem, o mercado materializa-se em doze a dezoito meses.

Qual vai ser o evento desencadeador, aqui? A resposta honesta é que não sabemos. A força estrutural é o regulamento da UE de 2024 sobre a recolha e partilha de dados relativos aos serviços de alojamento de curta duração, que entra em vigor de forma faseada nos próximos anos e obriga as plataformas de reservas a transmitir os dados de atividade dos anfitriões às autoridades nacionais. Essa mudança de visibilidade é exatamente a alteração que torna a fiscalização economicamente racional para os reguladores pela primeira vez. As plataformas iluminam os anfitriões. Os reguladores fiscalizam os iluminados. O mercado acorda.

A faísca concreta pode ser uma coima. Pode ser uma fuga de dados. Pode ser uma notícia mediática sobre um resort ou um prédio cujos registos de comunicação chegam a um jornalista com tempo para perguntar se os documentos batiam certo. Não estamos no negócio de prever que faísca, nem quando. Estamos no negócio de reconhecer a forma e estar preparados.

Portanto, a pergunta para quem está a construir infraestrutura num mercado com esta forma é a pergunta que todos os fornecedores que vieram antes de nós tiveram de responder. Espera-se pelo evento desencadeador e tenta-se escalar para ele quando chegar, ou constrói-se agora e vende-se algo que o mercado quer hoje, com a infraestrutura por vender como uma propriedade discreta que se torna estruturante na manhã seguinte ao gatilho?

Fizemos a segunda aposta. A arquitetura fica dentro de um produto pelo qual o mercado está a pagar hoje por uma razão completamente diferente.

Como seria uma verificação a sério

Se um regulador realmente ligasse, se o contrato com o subcontratante fosse testado num tribunal, se o endereço se revelasse ser do anfitrião, o que defenderia, de facto, o anfitrião?

A resposta honesta é que há duas perguntas distintas que o regulador poderia fazer, e as respostas vêm de partes diferentes da arquitetura.

A primeira pergunta é se o documento era real. É aqui que os especialistas mais fortes da categoria, em particular a Chekin, já fazem um trabalho a sério. As somas de controlo da zona de leitura mecânica apanham uma classe de documentos adulterados. A correspondência biométrica com a selfie apanha substituições de identidade. A deteção de vivacidade apanha um vídeo gravado ou uma impressão de alta resolução. Para os operadores que compram o escalão de verificação, este trabalho acontece a sério. Não vamos fingir o contrário. A propriedade arquitetónica que mantemos contra isto é mais estreita e complementar: duas leituras estruturalmente independentes do documento, cada uma a partir de uma passagem visual separada, com prompts e contexto diferentes, que têm de concordar em cada campo antes de qualquer campo ser submetido. Se as duas leituras discordarem, o sistema pára e mostra ambas as leituras ao anfitrião. A MRZ apanha a classe criptográfica de adulteração. O portão de concordância de duas leituras apanha a classe do erro silencioso de extração, em que uma leitura única produz um campo confiantemente errado que um sistema de leitura única submeteria. Ambas as camadas importam. Nós construímos a segunda; os especialistas mais fortes constroem a primeira; numa categoria que levasse a lei a sério, as duas estariam presentes no mesmo encadeamento, e o anfitrião teria um registo de ambas.

A segunda pergunta, e a mais difícil, é se o anfitrião verificou o documento. É a pergunta a que o marketing da Chekin responde com "no manual review needed". É precisamente a pergunta que a lei coloca ao anfitrião. A defesa do responsável pelo tratamento, perante um regulador, não é que um sistema automatizado, na nuvem do fornecedor, deu o documento como válido. A defesa é que o anfitrião viu o documento, viu os dados extraídos dele, comparou um com o outro e premiu submeter. Sem essa cadeia, uma verificação automatizada na nuvem do fornecedor, sem passo de revisão visível ao anfitrião, é um ato que o fornecedor executou, não um ato que o anfitrião executou. O contrato entre eles pode mudar dinheiro de mãos perante um falso positivo. Não muda o endereço regulatório.

A arquitetura que estamos a construir é moldada pela segunda pergunta mais do que pela primeira. O anfitrião aprova a ação, e o que o anfitrião aprova são os onze campos que o documento produziu, mostrados ao lado da imagem do documento, num quadro que o anfitrião lê. A aprovação é amarrada criptograficamente à ação e aos bytes renderizados que o anfitrião viu. A trilha de auditoria regista o que o anfitrião viu no momento da decisão, não o que alguém reconstruiu depois. A submissão ao regulador é um botão que o anfitrião carrega, não uma chamada de retorno que uma automação dispara. Esta é a diferença entre um sistema que automatiza o trabalho e um sistema que automatiza uma ação regulada. A linha que não vamos cruzar é a linha em que a autorização do anfitrião deixa de ser do anfitrião.

Os dados são depois eliminados, e a eliminação fica registada numa cadeia à prova de adulteração que pertence ao anfitrião. Não num servidor de um fornecedor. Não na plataforma. O anfitrião poderá produzir um certificado de eliminação para qualquer documento que o sistema tenha tratado, sem precisar de pedir autorização a um fornecedor, a uma plataforma ou a um regulador. Eliminação demonstrável é a resposta à pergunta mais comum que um hóspede faz: o que acontece ao meu passaporte. É também a resposta à pergunta mais comum que um futuro regulador vai fazer: provem que o princípio da minimização de dados foi cumprido para este hóspede, nesta comunicação, nesta data.

O núcleo de raciocínio que faz tudo isto faz mais uma coisa que os especialistas da categoria, na maioria, não fazem. Redige o pedido ao hóspede na língua do próprio hóspede, na voz do anfitrião, explicando com clareza por que é que a lei exige o documento e o que lhe acontece depois. Lê as respostas do hóspede. Quando o hóspede resiste, está concebido para ler a preocupação concreta por detrás da resistência e redigir uma resposta a essa preocupação, para o anfitrião enviar. O padrão da categoria é uma ligação genérica de check-in que aterra no email do hóspede num inglês duro. A arquitetura que estamos a construir tem por objetivo ler a conversa, não seguir um guião. Quanto é que isto eleva a aceitação é uma pergunta a que os primeiros pilotos estão prestes a responder.

Nenhuma destas propriedades é teórica. O portão de concordância de duas leituras, a aprovação amarrada ao raciocínio, os cliques irreversíveis reservados ao anfitrião e as comunicações multilingues com o hóspede estão em produção hoje. A trilha de auditoria também está em produção, com a propriedade de que o operador vê tipos de eventos, contagens e hashes, mas nunca o nome do hóspede, o número do documento, nem qualquer elemento dos dados de categoria especial. A experiência do certificado de eliminação está em construção, em cima da mesma cadeia de auditoria. Cada propriedade está no sistema que está a ser instalado na máquina da primeira anfitriã em Portugal enquanto este ensaio está a ser escrito.

O que estamos a fazer quanto a isto

Estamos a construir esta arquitetura e não a estamos a vender.

O mercado não está a pagar por cumprimento verificado, porque o mercado não acredita que cumprimento verificado seja aquilo de que precisa. Não temos questão a colocar a essa crença. Está empiricamente correta, dado o estado de fiscalização do regime hoje. O que o mercado está a pagar é o trabalho diário que o anfitrião está a fazer sozinho ou a pagar a um co-anfitrião para fazer. Um co-anfitrião em Portugal custa entre quinze e vinte e cinco por cento da receita. Um contabilista custa mais. O trabalho que o anfitrião está hoje a fazer ou a pagar é a verdadeira âncora contra a qual um produto de cumprimento verificado é precificado. As ferramentas de ponto, entre quatro e seis euros por propriedade, ficam abaixo do chão desse preço. O trabalho é o teto. A folga entre os dois é o espaço.

Estamos a construir dentro desse espaço. A anfitriã que está a instalar o sistema hoje fá-lo porque está farta de escrever os mesmos onze campos no mesmo portal à meia-noite depois de um hóspede chegar tarde, numa língua que o portal só aceita escrita de uma forma. O sistema escreve a mensagem educada ao hóspede na sua língua. O sistema extrai o documento. O sistema preenche os onze campos. A anfitriã revê-os num quadro, carrega em Guardar e vai dormir. É este o valor que ela sente. A arquitetura fica por detrás, como propriedade discreta da forma como foi construída.

Um leitor atento poderia argumentar que a verificação já está no menu, que os operadores a podem pagar hoje, e que a escolha do mercado de não pagar é a escolha do mercado. A objeção é correta, e não altera a aposta. Não estamos a vender verificação como escalão por cima da submissão. Estamos a vender o trabalho diário que a anfitriã está a fazer à meia-noite, a um preço ancorado no trabalho humano que ela teria, de outro modo, de pagar. A arquitetura fica dentro desse produto como propriedade da forma como foi construída. O operador não tem de escolher pagar a mais por verificação. Recebe-a porque comprou o alívio do trabalho. Na manhã em que a fiscalização chegar, são eles os que têm a arquitetura que não escolheram conscientemente comprar.

Na manhã em que a lei for aplicada, o valor que ela sente continua igual. A arquitetura deixa de ser uma propriedade discreta e torna-se a única coisa que importa. Os anfitriões que já a têm acordam numa posição diferente da dos anfitriões que não a têm. Não são os únicos que vão resolver o problema nesse momento. São os que não vão ter de o resolver.

Não sabemos em que manhã isso é. Sabemos que a manhã chega para todos os regimes com esta forma, porque todos os regimes que tiveram esta forma já a tiveram antes. A arquitetura demora mais a construir do que o mercado demora a acordar. Quando o mercado acorda, a arquitetura é o que está na prateleira.

Escrevemos isto em público porque a análise parece mais útil como leitura do que como uma apresentação de slides para dez reuniões. A categoria de operadores a que este ensaio se refere é grande, dispersa e largamente silenciosa. O próximo operador que ler isto e reconhecer o resort do parágrafo inicial vai ficar a saber coisas sobre os seus próprios arranjos de cumprimento que não sabia há uma hora. Alguns desses operadores vão decidir que gostariam de ter a arquitetura por sua quando ela importar. Gostávamos de saber deles.

Uma nota sobre o que este ensaio não é

Isto não é um argumento de venda. A página do produto está em get-obra.com.

Também não é uma crítica aos concorrentes. Os fornecedores nomeados neste ensaio são bons produtos a fazer o que os seus clientes lhes pagam para fazer. O mercado que servem decidiu o que está a comprar. A verificação está no menu, no topo da escada de preços, mas não é isso que o mercado está a comprar. Não pensamos que nenhuma das empresas nomeadas esteja a falhar a entregar o produto que prometeu. Pensamos que o produto que o mercado tem estado a pedir é um produto diferente daquele que a lei, de facto, exige.

Não é uma previsão. Não sabemos quando o evento desencadeador chega. Sabemos a forma, sabemos a arquitetura, e sabemos que os anfitriões que nos pagam pelo trabalho que o trabalho lhes retira do dia são os mesmos anfitriões que vão ter a arquitetura na manhã em que a fiscalização chegar.

Se vir algo neste ensaio em que nos enganámos, ou se a abertura lhe soar verdadeira na sua própria situação, um email para team@get-obra.com encontra-nos.