# Kulular Teknoloji, corpus em português

## Como decorre um projeto de software, da proposta à entrega

Fonte: https://kulular.com.tr/pt/publicacoes/como-decorre-um-projeto-de-software

Uma das primeiras perguntas de uma organização que quer encomendar software é como vai decorrer o processo. Quando vão ver o quê, o que se espera delas, quando se considera o trabalho concluído.
Neste artigo explico as etapas por que passa um projeto, da primeira reunião à manutenção. As etapas não têm a mesma duração em todos os projetos. Num trabalho pequeno, várias cabem numa só reunião. Mas nenhuma é saltada, porque a etapa saltada volta no fim do projeto sob a forma de surpresa.
Primeira reunião
Na primeira reunião não falamos de preço. Tentamos perceber o que se pretende, como funciona hoje o trabalho e o que precisa de mudar. Quem vai usar o sistema, que dados vai tratar, com que sistemas vai comunicar.
No fim desta reunião, às vezes dizemos que não é preciso software à medida. Se um produto pronto resolve o problema, dizê-lo logo no início poupa o tempo de todos.
Descoberta
Se a necessidade não está clara, propomos uma curta fase de descoberta. Alguns workshops, uma análise dos sistemas e dados existentes, o levantamento do fluxo de trabalho passo a passo. O resultado da descoberta é um documento escrito: âmbito, perfis de utilizador, integrações, dados, riscos conhecidos e incógnitas.
É a fase mais barata do projeto e a que mais dinheiro poupa. Corrigir uma necessidade mal compreendida num documento é muito mais fácil do que corrigi-la no código.
Proposta
A proposta baseia-se no documento de descoberta. Para cada pacote de trabalho fica escrito o que será feito, quanto tempo leva, o que se espera da organização e segundo que critério será aceite. O que fica fora do âmbito também fica escrito. É aqui que se define com quem ficam o código-fonte e os direitos de propriedade intelectual e como funcionará a manutenção.
Conceção
Antes de escrever código, concebemos o modelo de dados, a estrutura de permissões e os ecrãs principais. Mostramos os esboços dos ecrãs aos utilizadores reais da organização. As objeções que surgem nesta fase são muito mais baratas do que as que surgem depois.
Se vão ser tratados dados pessoais, também se decide nesta fase que dados são recolhidos e porquê, quem os pode ver e durante quanto tempo são conservados. Não são funcionalidades a acrescentar depois, fazem parte da arquitetura.
Desenvolvimento
Conduzimos o desenvolvimento em ciclos curtos. No fim de cada ciclo, a organização vê uma versão a funcionar no ambiente de testes. Se algo foi mal compreendido, nota-se em poucas semanas.
A cada alteração correm testes automáticos. Se um teste falha, essa versão não avança. Contámos como fazemos isto no nosso próprio site num artigo à parte.
Testes e aceitação
A aceitação faz-se segundo os critérios escritos na proposta. Para cada funcionalidade, critérios concretos do tipo «nesta situação dá este resultado». A organização experimenta estes critérios com os seus próprios dados, os pontos que não cumprem são registados e corrigidos.
Quando os critérios de aceitação não estão escritos, a discussão sobre «funciona?» é inevitável. Explicámos porquê no artigo sobre critérios de aceitação.
Entrada em produção
A entrada em produção não é um dia, é um pequeno plano. Se há dados a migrar do sistema antigo, as migrações de ensaio fazem-se antes. Fica escrito como voltar atrás se algo correr mal. Os utilizadores recebem uma formação curta e, nas primeiras semanas, as perguntas têm resposta rápida.
Manutenção
Depois da entrega continuam as atualizações de segurança, as atualizações de infraestrutura e pequenas melhorias. O âmbito da manutenção e o prazo para tratar um problema ficam por escrito na fase de proposta.
O código-fonte, a documentação e os passos de implementação são entregues à organização. Assim, se um dia quiser continuar com outra equipa, pode fazê-lo.
O papel da organização
Em todas estas etapas é preciso um interlocutor do lado da organização. Alguém que conheça o fluxo de trabalho, responda às perguntas em pouco tempo e possa experimentar as versões intermédias. O que abranda os projetos muitas vezes não é um problema técnico, é a falta deste interlocutor.
Em resumo
Primeira reunião, descoberta, proposta, conceção, desenvolvimento, aceitação, entrada em produção e manutenção. As etapas encurtam ou alongam consoante a dimensão do projeto, mas nenhuma é saltada. Ter por escrito o que se entrega no fim de cada etapa evita surpresas no fim do projeto.

## Dez perguntas a fazer ao escolher uma empresa de software

Fonte: https://kulular.com.tr/pt/publicacoes/escolher-uma-empresa-de-software

Quando uma organização procura uma empresa de software, costuma ter três ou quatro propostas na mão. Os preços são diferentes, os prazos também, mas os textos são muito parecidos. Todos falam de «metodologia ágil», «arquitetura escalável» e «solução ponta a ponta».
Estas palavras não distinguem uma empresa da outra. O que as distingue são as respostas às perguntas feitas na primeira reunião. Neste artigo enumero essas perguntas. Como empresa de software, também nos fazem estas perguntas, e queremos que as façam.
1. Como definem o âmbito?
Uma boa empresa não diz um preço na primeira reunião. Primeiro tenta perceber o que há a fazer. Quem vai usar o sistema, como funciona hoje o trabalho, com que sistemas tem de comunicar, que dados vai tratar.
Um preço dado sem resposta a estas perguntas não é uma estimativa, é uma esperança. Se a proposta não explica como foi definido o âmbito, pergunte.
2. Escrevem o que não sabem?
Todos os projetos começam com incógnitas. Quantos dados virão do sistema antigo, se a documentação de uma integração está atualizada, como os utilizadores vão reagir ao novo ecrã.
Uma empresa que escreve isto claramente na proposta está a mostrar onde está o risco. Uma proposta que enterra tudo num preço fechado torna o risco invisível. O risco não desaparece, apenas aparece mais tarde.
3. Com base em quê vamos aceitar a entrega?
A maior parte dos desacordos em projetos de software nasce da pergunta «funciona?». A causa não é técnica. Simplesmente, ninguém escreveu à partida o que significa «funciona».
Faça esta pergunta. Para cada funcionalidade, deve estar escrito em que situação se considera concluída. Explicámos isto em detalhe no artigo sobre critérios de aceitação.
4. Com que frequência vamos ver algo a funcionar?
Não ver durante seis meses um software que só será entregue daqui a seis meses é o terreno dos mal-entendidos mais caros. Peça para ver, a intervalos regulares, uma versão em que se possa clicar. De duas em duas semanas ou uma vez por mês, mas com regularidade.
5. Com quem ficam o código-fonte e os direitos de propriedade intelectual?
O contrato deve ter uma resposta clara a esta pergunta. O código-fonte é transferido para a organização, ou é concedido apenas um direito de utilização? O que acontece se a empresa fechar ou se os caminhos se separarem?
Se a resposta não ficar escrita, no dia em que quiser mudar de empresa pode ficar apenas com um programa que funciona.
6. Quem trata da manutenção depois da entrega?
O software não acaba no dia em que é entregue. Os sistemas operativos são atualizados, surgem falhas de segurança nas bibliotecas, os utilizadores trazem novas necessidades. Pergunte pelo âmbito, duração e preço da manutenção ainda na fase de proposta. O prazo para tratar um erro também deve ficar escrito.
7. Como protegem os dados?
Se o software vai tratar dados pessoais, a forma como a empresa encara esses dados percebe-se logo na primeira reunião. Fica registado quem acede a que dados? Onde estão as cópias de segurança? Em que país estão os servidores? Quem são os subcontratantes?
Se uma empresa responde a estas perguntas com «não se preocupe», passe para uma empresa que dê respostas concretas. A segurança dos dados é uma obrigação que a lei impõe ao responsável pelo tratamento. Encomendar o software a outra entidade não elimina essa obrigação.
8. Quem vai trabalhar no projeto?
A pessoa que vem à reunião comercial pode não ser a mesma que vai escrever o código. Isso é natural. Mas vai querer saber quem trabalha no projeto, quem decide e quem lhe responde. Uma empresa que apresenta a equipa pelo nome responde facilmente a esta pergunta.
9. Como fizeram um trabalho semelhante antes?
Em vez de uma lista de referências, peça que lhe contem um projeto. Onde tiveram dificuldades, o que mudaram, qual foi o resultado. Uma empresa capaz de contar a parte difícil de um projeto fê-lo de facto.
Por razões de confidencialidade, talvez não possam dar o nome do cliente. É normal. Mas devem conseguir descrever o processo.
10. Há alguma razão para não fazermos este projeto?
A última pergunta é pouco habitual, mas diz muito. Uma boa empresa às vezes diz «não precisa de software à medida, este produto pronto resolve». Outras vezes diz «este âmbito não cabe neste orçamento». Ouvir isto mostra que está a falar com alguém que diz a verdade, mesmo correndo o risco de perder o trabalho.
Tratámos a decisão entre pacote pronto e software à medida num artigo à parte.
Que importância tem a proximidade
Para uma organização em Ancara, trabalhar com uma empresa de software em Ancara é uma vantagem, mas não uma obrigação. Alguns workshops presenciais nas primeiras semanas ajudam a compreender o âmbito mais depressa. Ver juntos um sistema a funcionar no terreno também.
Depois, o que conta não é a distância, é a disciplina da comunicação. Registar as decisões por escrito, ver versões com regularidade e ter resposta às perguntas no mesmo dia vale mais do que estar no mesmo edifício.
Em resumo
O que distingue uma empresa de software não é o preço da proposta, são as respostas na primeira reunião. Uma empresa que responde de forma concreta sobre âmbito, critérios de aceitação, código-fonte, manutenção e segurança dos dados também trabalha de forma concreta ao longo do projeto.

## Pacote pronto ou software à medida: como decidir

Fonte: https://kulular.com.tr/pt/publicacoes/pacote-ou-software-a-medida

Algumas das organizações que nos procuram não precisam, na verdade, de software à medida. Um produto pronto, bem configurado, resolve o problema. Para uma empresa de software, dizer isto significa perder um trabalho no curto prazo. No longo prazo, sai muito mais barato do que começar o projeto errado.
Neste artigo explico como decidimos entre um pacote pronto e software à medida.
Primeira pergunta: até que ponto o seu trabalho é padrão?
Contabilidade, processamento salarial, e-mail, documentos de escritório. Estas tarefas funcionam praticamente da mesma maneira em todas as organizações, e a legislação também as torna parecidas. Nestas áreas há produtos maduros e muito usados. Desenvolvê-los de raiz raramente faz sentido.
O fluxo de trabalho que distingue a organização das outras é outra coisa. A forma como um hospital liga os dados dos equipamentos ao circuito clínico, o método de avaliação de uma instituição de ensino, o processo de produção que uma empresa desenvolveu. Um produto pronto só se adapta a estes fluxos se a organização se adaptar ao produto.
A regra é simples. Se o trabalho é padrão, produto pronto. Se aquilo que torna o seu trabalho diferente está dentro do software, software à medida.
Calcule o custo a cinco anos
O primeiro ano de um pacote pronto costuma parecer barato. A instalação é rápida, a primeira fatura é pequena. Parar a comparação aqui é enganador.
Numa conta a cinco anos aparecem outras rubricas. A licença, que cresce com o número de utilizadores. As adaptações para o trabalho que não cabe no pacote. Refazer as adaptações que deixam de funcionar na versão seguinte. O segundo processo, informal, criado para o trabalho que não cabe no pacote, que muitas vezes é um ficheiro Excel.
O software à medida também tem um custo a cinco anos. O desenvolvimento inicial, o alojamento e a manutenção. A diferença é que esse custo é mais previsível e fica sob controlo da organização. Tratámos estas rubricas no artigo sobre custos.
Onde ficam os dados?
A maioria dos produtos prontos na nuvem tem os servidores fora da Turquia. Para uma organização que trata dados pessoais, isto significa, do ponto de vista legal, uma transferência de dados para o estrangeiro. Há forma de o fazer, mas a decisão deve ser tomada de forma consciente.
Há ainda a questão do acesso aos dados. Quando quiser deixar o produto pronto, em que formato, em quanto tempo e com que grau de completude consegue recuperar os seus dados? Faça esta pergunta antes do contrato. Um produto com uma resposta vaga já o prendeu a si.
A dependência existe nos dois sentidos
Num pacote pronto, a dependência é em relação ao produto. Não é a organização que decide os aumentos de preço, as funcionalidades retiradas nem o rumo do produto.
No software à medida também há dependência, desta vez em relação à empresa que o desenvolve. Se o código-fonte não está consigo, se a documentação não foi escrita e se outra equipa não consegue ler o código, mudar de empresa torna-se quase impossível. Por isso, no software à medida deve exigir que o código-fonte, a documentação e os passos de implementação sejam entregues à organização.
Muitas vezes a resposta é ambos
As estruturas mais saudáveis que vemos são mistas. As tarefas padrão funcionam em produtos prontos. O fluxo de trabalho que distingue a organização funciona em software à medida. Entre os dois há uma boa integração, para que os mesmos dados não sejam introduzidos duas vezes.
Nesta estrutura, o âmbito do software à medida diminui e a entrega é mais rápida. E os produtos prontos ficam livres das tarefas para as quais não servem.
Quando dizemos que é melhor não desenvolver
Quando uma organização nos procura e vemos que a necessidade pode ser resolvida com um produto muito usado, dizemo-lo. Se for preciso, ajudamos a ligar esse produto aos sistemas existentes. Recomendamos software à medida onde ele faz realmente a diferença.
Em resumo
Produto pronto para o trabalho padrão, software à medida para o trabalho que distingue a organização. Compare com o custo de cinco anos, não do primeiro ano. E tenha em conta onde ficam os dados e como os recupera quando sair.

## O que determina o custo de um software à medida

Fonte: https://kulular.com.tr/pt/publicacoes/custo-de-software-a-medida

«Quanto custa este software?» é a pergunta que mais nos fazem. A resposta não é um número único, e dizê-lo parece uma forma de fugir à pergunta. Não é. Um número dado sem conhecer as rubricas que determinam o custo ou é mais alto do que devia, ou vai subir a meio do projeto.
Neste artigo explico que rubricas determinam o custo de um software à medida e em que reparar ao ler uma proposta. Não dou valores, porque cada projeto é diferente. Mas ver de onde vem o valor torna muito mais fácil comparar propostas.
O número de ecrãs é uma medida enganadora
O custo do software é muitas vezes pensado em número de ecrãs. Um ecrã de login, uma lista, um formulário, um relatório. Mas os ecrãs são a parte visível do custo.
Dois formulários com o mesmo aspeto podem ter custos muito diferentes. Um grava os dados introduzidos numa tabela. O outro valida esses dados, mostra-os a pessoas diferentes consoante as permissões, envia-os para outro sistema e regista cada alteração. O custo é determinado pelas regras por trás do ecrã.
Integrações
Um software raramente funciona sozinho. Sistema de contabilidade, autenticação, pagamentos, e-mail, os sistemas antigos da organização ou um serviço público. Cada ligação é um trabalho à parte.
Ligar a um serviço com boa documentação e uma interface sólida pode levar alguns dias. Ligar a um sistema antigo com documentação incompleta e sem ambiente de testes pode levar semanas. Perguntar, na fase de proposta, pela documentação e pelas possibilidades de teste de cada integração clarifica a parte mais incerta do custo.
Dados e migração
Se o novo software não começa com uma base de dados vazia, vai ser preciso migrar dados do sistema antigo. Na maioria das propostas isto fica numa só linha, e é um dos pontos onde os projetos mais derrapam. Explicámos porquê no artigo sobre migração de dados.
Segurança e legislação
Um software que trata dados de saúde, dados de alunos ou dados financeiros exige mais trabalho do que uma ferramenta interna com o mesmo aspeto. Acesso baseado em funções, registos de acesso, cifragem, aplicação de prazos de conservação, eliminação e anonimização. Tudo isto é difícil de acrescentar depois. Incluí-lo no âmbito desde o início é mais barato e mais seguro.
Incerteza
Todos os projetos têm incógnitas. Uma boa proposta escreve-as à parte e diz como serão tratadas. Uma má proposta ou acrescenta a incerteza ao preço em silêncio, ou não a tem em conta de todo. A segunda é mais perigosa, porque a diferença aparece a meio do projeto numa fatura adicional.
A melhor forma de reduzir a incerteza é pôr uma curta fase de descoberta no início do projeto. Nessa fase clarificam-se o âmbito, as integrações e os dados. O desenvolvimento propriamente dito é depois orçamentado com um valor mais sólido.
Testes e aceitação
Os testes são a rubrica mais exposta a cortes. Quando são cortados, são também a rubrica cujo preço se paga mais tarde. Testes automáticos, testes de aceitação e ensaios com utilizadores reais. Se o esforço reservado aos testes não aparece na proposta, ou não vai ser feito, ou vai ficar a cargo da sua equipa.
Depois da entrega
O custo do software não acaba no dia da entrega. Continuam o alojamento, as cópias de segurança, as atualizações de segurança, a atualização das bibliotecas usadas e pequenas melhorias. Ver estas rubricas à parte na fase de proposta evita surpresas no fim do primeiro ano.
Ao ler uma proposta
Ao comparar várias propostas, escreva lado a lado o que cada uma inclui. As integrações estão incluídas? E a migração de dados? Quanto esforço vai para testes, como é orçamentada a manutenção, com quem fica o código-fonte? A maior parte das diferenças de preço mostra que não se está a orçamentar o mesmo trabalho.
Em resumo
O custo de um software à medida não é determinado pelos ecrãs, mas pelas regras por trás deles, pelas integrações, pelos dados, pela segurança, pelos testes e pela manutenção. Uma proposta que escreve estas rubricas com clareza, mesmo que pareça mais cara, sai muitas vezes mais barata.

## Como construir um site institucional: notas sobre o nosso próprio site

Fonte: https://kulular.com.tr/pt/publicacoes/como-construimos-este-site

O site de uma empresa de software é o primeiro software que a empresa escreve. Quem o visita não vê o código, mas vê o resultado. Se a página demora a abrir, se ficou uma frase em turco noutra língua, se o formulário de contacto falha em silêncio, o visitante atribui isso ao trabalho da empresa.
Por isso, construímos o site não como uma brochura, mas como um pequeno produto. Escrevo abaixo que decisões tomámos, porquê, e onde nos enganámos.
Geração estática
O site foi escrito com Next.js. Na primeira versão, as páginas eram geradas de novo no servidor a cada pedido. A causa era uma linha inocente: o layout raiz lia o cabeçalho do pedido para descobrir a língua. O Next considera dinâmica qualquer página onde vê isso.
O resultado era que a Cloudflare não conseguia guardar nenhuma página em cache. Cada visita ia até ao servidor na Hetzner. Medido localmente, o tempo até ao primeiro byte era de poucos milissegundos. Ou seja, o código não era lento. O problema ia surgir com a escala.
A solução foi deduzir a língua a partir do endereço e não do pedido. Cada língua tem o seu próprio layout raiz, e a língua fica clara pela pasta onde a página está. Hoje, todas as cerca de trezentas páginas são geradas uma única vez, durante a compilação.
Sete línguas e coerência
O site está publicado em turco, inglês, francês, português, alemão, espanhol e árabe. A tradução em si é a parte fácil. O difícil é que, quando um texto muda, mude em sete sítios ao mesmo tempo.
A maioria dos erros que encontrámos nas primeiras revisões vinha do mesmo padrão. Uma longa cadeia de condições que escolhia o texto conforme a língua caía em silêncio no último ramo quando se esquecia de uma língua. E o último ramo era quase sempre o turco. Era assim que aparecia uma frase em turco a meio de uma página em francês.
Resolvemos isto com uma função auxiliar. Qualquer sítio que escolha um texto tem de fornecer as sete línguas de uma vez. Se faltar uma, o código não compila. O erro é apanhado antes de chegar à produção.
Os títulos académicos eram um problema parecido. Numa tradução, o título «Doç. Dr.» tinha-se transformado em professor catedrático. Agora o título não é traduzido em nenhuma língua. Vem do registo em turco, e um teste verifica isso a cada push.
Testes
Não montámos uma framework de testes pesada. Escrevemos nove testes com o módulo de testes do próprio Node. Cada um apanha um erro que já nos aconteceu de verdade.
Entre eles: o título manter-se igual em todas as línguas, não haver travessões longos em nenhum texto, o nome da marca não ser traduzido, cada artigo em turco ter equivalente nas outras seis línguas e os textos jurídicos não serem resumidos na tradução. O último teste é grosseiro, mas funciona: se a página jurídica numa língua for mais curta do que sessenta por cento da versão turca, é muito provável que tenha sido resumida.
A cada push para o GitHub correm a verificação de tipos, o lint, estes testes e a compilação de produção. Se algum falhar, a versão não vai para produção.
Segurança
A política de segurança de conteúdo é rigorosa. Não se pode carregar nenhum script, tipo de letra ou imagem de um domínio externo. Os tipos de letra vêm do nosso próprio servidor. Assim, o navegador do visitante não envia pedidos a terceiros ao abrir a página. O Google Analytics só é carregado se o visitante der consentimento.
O ecrã do protocolo de trabalho na página inicial envia a um modelo de linguagem o texto que o visitante escreve. É o ponto do site mais fácil de usar de forma abusiva. Alguém que queira usar de graça um modelo pago pode chamar diretamente o endpoint. Impedimos isso com várias camadas: a verificação de que o pedido vem da nossa página, um bilhete assinado de curta duração e utilização única, um limite por hora e por dia para cada endereço, um teto diário para o site inteiro e um limite para o número de pedidos que podem ir ao modelo em simultâneo.
Implementação
O código está no GitHub. No servidor da Hetzner corre o Coolify, que a cada push para o ramo principal volta a compilar o site como imagem Docker e o coloca em produção. Uma implementação demora cerca de dois minutos e meio.
À frente está a Cloudflare. Com a passagem para a geração estática, também o HTML passou a poder ficar em cache, e as páginas ficam lá guardadas até uma hora.
Onde nos enganámos
A cache foi a fonte da velocidade, mas também de um equívoco. Pusemos uma nova versão em produção, o Coolify disse que tinha corrido bem, mas a página inicial continuava a aparecer na versão antiga. A causa era simples. A Cloudflare não pedia a cópia nova enquanto a que tinha não expirasse.
A solução certa é limpar a cache automaticamente no fim de cada implementação. O processo de publicação só está concluído quando termina no sítio que o visitante vê, e não apenas no servidor.
Há também a acessibilidade. A análise automática não encontrava erros nas páginas. Mas as pequenas etiquetas da página inicial estavam sobre uma fotografia semitransparente, e a ferramenta de análise não consegue medir o contraste sobre uma fotografia. Medimos à parte os píxeis por trás das etiquetas e o rácio rondava 3:1. Depois de esbater um pouco a fotografia e escurecer as etiquetas um tom, passou acima de 5:1. Mesmo quando a ferramenta diz «sem erros», é preciso olhar.
Porque contamos isto
É fácil dizer a um cliente «entregamos software que funciona». Quando escrevemos abertamente o que fizemos neste site, também se torna fácil ver em que se apoia essa frase.

## Um agente de IA que responde a e-mails: como definimos os limites do KAI

Fonte: https://kulular.com.tr/pt/publicacoes/os-limites-da-kai

A KAI é o membro de inteligência artificial da nossa equipa. Aparece com o seu nome na página da equipa, porque não quisemos esconder nos bastidores o uso de inteligência artificial. Mas dar um nome a uma inteligência artificial é a parte fácil. A verdadeira questão é quanto trabalho lhe deixamos.
Hoje, a KAI lê os e-mails que chegam à empresa. Responde sozinha aos de rotina e marca reuniões. Nos que não são rotina, apenas prepara um rascunho, e é alguém da equipa que decide se o envia ou não. Este texto explica onde traçámos essa linha e porquê.
As duas opções fáceis estavam erradas
Há duas opções que ocorrem logo. A primeira é o agente enviar tudo sozinho. A segunda é cada resposta ser aprovada por uma pessoa antes de ser enviada.
A primeira é claramente arriscada. Um modelo de linguagem pode inventar um preço ou um prazo de entrega com um tom muito seguro. A outra parte lê isso como um compromisso da empresa.
A segunda parece segura, mas na prática não funciona. Já o explicámos noutro artigo sobre governação da inteligência artificial. Num sistema que pede aprovação para cada resposta, a taxa de aprovação aproxima-se, ao fim de algum tempo, dos cem por cento. Quem aprova deixa de ler o texto. No papel há supervisão humana. Na realidade, é o sistema que decide.
Com que critério traçámos a linha
Para considerar um e-mail de rotina, fizemos duas perguntas. A resposta é conhecida de antemão? Se estiver errada, corrige-se com facilidade?
Se a resposta às duas for sim, a tarefa é de rotina. Propor um horário para uma reunião, confirmar a receção de um documento ou responder a uma pergunta geral com a informação do site entram nesta categoria. Se a KAI propuser um horário errado, a outra parte corrige-o na mensagem seguinte e ninguém sai prejudicado.
Se a resposta a uma delas for não, a tarefa não é de rotina. Toda a correspondência que envolva preços, âmbito, contratos, prazos de entrega e dados pessoais está nesta categoria. Aqui a KAI prepara um rascunho, mas a mensagem não sai sem a decisão de alguém da equipa.
A vantagem desta distinção é manter a aprovação humana rara, mas com significado. Cada mensagem que pede aprovação exige mesmo reflexão. Quem aprova sabe que o que tem à frente é importante.
Escrever na assinatura que é inteligência artificial
Na assinatura de cada e-mail que a KAI envia, indica-se que a mensagem foi escrita por um sistema de inteligência artificial. Fazemo-lo por duas razões.
A primeira é a honestidade. A outra parte não deve julgar que está a falar com uma pessoa e confiar em função disso. A segunda é a regulamentação. O Regulamento (UE) 2024/1689 exige que as pessoas saibam quando estão a interagir com uma inteligência artificial. Para os nossos interlocutores na Europa, isto é uma obrigação. Para os que estão na Turquia, é também um bom hábito.
O que ela não pode fazer
A KAI não tem poderes de assinatura na empresa. Não pode apresentar propostas, celebrar contratos nem interpretar legislação. Estes limites não estão apenas numa lista de regras. Estão também traçados nas ferramentas que o agente pode usar. Quando não se dá uma permissão a um agente, também não é preciso confiar nele para que não a use.
A KAI acede a um modelo de linguagem através do OpenRouter. Isto significa que a correspondência vai para um prestador de serviços no estrangeiro. Explicámo-lo à parte no nosso aviso de privacidade. Aí pedimos também que não se enviem por e-mail informações confidenciais, dados pessoais de categorias especiais ou segredos comerciais.
Onde este desenho tem dificuldades
A linha entre rotina e não rotina nem sempre é nítida. «Não posso ir à reunião, pode ser noutro dia?» é uma mensagem de rotina. «Não posso ir à reunião porque vamos suspender o projeto» já não é. As duas começam com a mesma frase.
Por isso, em caso de dúvida, o comportamento por omissão é preparar um rascunho. A KAI não considera de rotina uma mensagem sobre a qual não tem certeza. Errar num sentido, ou seja, deixar trabalho a uma pessoa sem necessidade, sai mais barato do que errar no sentido contrário.
O que levamos para os projetos dos clientes
O critério que usamos no nosso próprio trabalho passa também para os sistemas que construímos para os clientes. Não ligamos nem desligamos a autonomia de um agente com um único interruptor. Classificamos as tarefas consoante a resposta seja ou não conhecida de antemão e consoante o erro seja ou não reversível. Conforme a categoria, o agente ou termina a tarefa ou deixa um rascunho.
Este critério não é perfeito. Mas conseguimos escrever claramente onde se situa, e um limite que conseguimos escrever é um limite que conseguimos verificar.

## Migração de dados para um novo software: porque contamos os registos três vezes

Fonte: https://kulular.com.tr/pt/publicacoes/migrar-dados-de-sistemas-antigos

Quando uma organização muda para um novo sistema, fala-se sobretudo das funcionalidades do novo sistema. Os ecrãs, os relatórios, a aplicação móvel. A forma de migrar os dados do sistema antigo costuma ficar para o fim, e despacha-se com um «fazemos uma transferência».
É aí que os projetos realmente encravam. O código funciona, os ecrãs estão prontos, mas parte dos registos de clientes chega incompleta e ninguém sabe quantos faltam nem porquê.
Neste artigo conto o que verificamos antes, durante e depois da migração.
Primeiro, o inventário
Não começamos a migração com a primeira linha de código, mas com uma lista. Que tabelas existem no sistema antigo, quantos registos tem cada uma, o que significa cada campo, qual deles já não é usado.
A surpresa mais frequente nesta lista é a mesma informação estar guardada em dois sítios. A morada do cliente está tanto na tabela de clientes como na tabela de faturas, e as duas não coincidem. Decidir qual se considera correta não é uma decisão técnica. É uma decisão da organização. É preciso perguntá-lo antes da migração.
A segunda surpresa é o sistema antigo ser um ficheiro Excel. No Excel, qualquer campo sem regras é um campo onde, um dia, alguém escreveu outra coisa «temporariamente». Aparecem linhas com «não há» na coluna da data e células com dois números na coluna do telefone.
Mapeamento de campos
Dois sistemas não guardam os dados da mesma forma. O sistema antigo pode ter um único campo «nome completo» e o novo ter dois campos separados. A cidade, que no sistema antigo era texto livre, pode ser escolhida de uma lista no novo.
Para cada campo escrevemos uma regra de mapeamento: o campo antigo, o campo novo e a conversão entre eles. Os registos que não cumprem a regra não são corrigidos em silêncio. Vão para uma lista à parte. Essa lista é revista com a organização, registo a registo.
A correção silenciosa parece tentadora, mas é a pior coisa que se pode fazer numa migração. Um registo errado já estava errado no sistema antigo. Se for corrigido por palpite durante a migração, passa a ser no novo sistema um registo que parece certo mas está errado. Ninguém voltará a dar por isso.
Contar três vezes
Quando a migração termina, para dizer que está «concluída», contamos os registos em três pontos.
O primeiro é a origem. O número de registos a migrar no sistema antigo, tabela a tabela.
O segundo é a transferência. O número de registos que o script de migração leu, converteu e separou para a lista à parte.
O terceiro é o destino. O número de registos realmente criados no novo sistema.
A origem tem de ser igual à soma dos transferidos com os separados. E os transferidos têm de ser iguais ao destino. Se estas duas igualdades não se verificam, a migração não terminou, por pequena que seja a diferença. Uma diferença de umas centenas de registos significa perder o histórico de umas centenas de clientes.
Os números baterem certo não chega por si só. Os números podem bater certo e o conteúdo estar corrompido. Por isso abrimos lado a lado, nos dois sistemas, registos escolhidos ao acaso e comparamo-los campo a campo. Para campos críticos, como montantes e datas, calculamos também à parte, dos dois lados, totais e valores de resumo.
Migração de teste e plano de reversão
Não fazemos a migração real pela primeira vez no dia real. Primeiro fazemos pelo menos duas migrações de teste com uma cópia dos dados. Em cada teste medimos o tempo, analisamos os registos separados e corrigimos as regras de mapeamento.
Antes da migração real, o plano de reversão fica por escrito. O que se faz se a migração ficar a meio ou se os números não baterem certo, até que ponto se pode voltar ao sistema antigo, quem toma essa decisão. Quando estas perguntas se fazem no dia da migração, as respostas são dadas à pressa.
Os dois sistemas juntos durante pouco tempo
Sempre que possível, depois de o novo sistema arrancar, o sistema antigo fica também disponível durante pouco tempo, só em modo de leitura. Se um registo parecer incompleto ou errado, é possível consultar o sistema antigo e comparar.
O fim desse período é definido desde o início. Se não for, os dois sistemas convivem lado a lado durante meses e volta a discutir-se qual deles está certo.
Não migrar também é uma decisão
Nem todos os registos antigos têm de passar para o novo sistema. Migrar dados cujo prazo de conservação expirou obriga a organização a continuar a guardá-los sem necessidade. No caso dos dados pessoais, isto pode ainda tornar-se uma violação de uma obrigação legal.
A migração é um bom momento para fazer esta triagem. Identificamos os registos cujo prazo de conservação expirou, deixamo-los fora da migração com a aprovação da organização e registamos a eliminação. Assim, o novo sistema começa limpo.
Em resumo
A migração de dados não é uma transferência. É um pequeno projeto. Uma migração feita sem inventário, mapeamento, contagem em três fases, migração de teste e plano de reversão faz o novo sistema perder a confiança logo no primeiro dia.

## Quando é que a supervisão humana não funciona num sistema de IA

Fonte: https://kulular.com.tr/pt/publicacoes/supervisao-de-ia

Ao desenvolver sistemas de IA para organizações, uma das primeiras coisas pedidas é a aprovação humana. Este artigo explica como perceber se essa aprovação funciona de facto no sistema.
Quando se fala de governação da inteligência artificial, a frase mais ouvida é esta. "Há aprovação humana, a decisão não fica entregue à máquina."
Quando ouço essa frase, só faço uma pergunta. Qual é a vossa taxa de aprovação?
Não chega resposta, porque não se mede. Nos poucos lugares onde se mede, o resultado costuma ultrapassar os noventa e oito por cento. Ou seja, a pessoa supervisora contraria o modelo uma vez em cada cinquenta decisões. Dizer que nesse quadro existe supervisão humana é formalmente correto mas funcionalmente falso. Quem decide de facto é o sistema; a pessoa apenas assina.
Por que razão o botão de aprovação não funciona
A causa não é má-fé, é o desenho.
Se a um utilizador se mostram trezentas recomendações por dia e se lhe pede que aprove cada uma, esse utilizador automatiza-se rapidamente. Se a taxa de acerto do modelo for alta, isso acelera ainda mais, porque também nos poucos casos em que rejeita, o modelo costuma ter razão, e o utilizador deixa de confiar no seu próprio critério.
Na literatura chama-se a isto confiança excessiva na automação, e é um fenómeno bem conhecido. Ou seja, quanto melhor o sistema funciona, mais fraca fica a supervisão humana. É um facto que tem de ser tido em conta ao conceber a supervisão.
As três condições que tornam a supervisão significativa
Para que a supervisão seja funcional, é preciso que três coisas existam em simultâneo.
A pessoa supervisora tem de conseguir ver o fundamento da recomendação. Se não se mostrar a partir de que dados de entrada o modelo chegou àquele resultado, a pessoa só pode avaliar o resultado, e para avaliar o resultado teria de decidir tudo de novo por conta própria. Isto torna a supervisão praticamente impossível.
A rejeição tem de ser gratuita. Um utilizador a quem rejeitar exige preencher um formulário adicional, escrever uma justificação e obter a aprovação do superior, opta por não rejeitar. O fluxo de rejeição deve ser pelo menos tão simples quanto o de aprovação.
A rejeição tem de ter uma consequência. Se as recomendações rejeitadas ficarem anotadas algures e ninguém as vir, a pessoa supervisora nota isso e, com o tempo, perde o interesse. Fazer com que os casos rejeitados alimentem o aperfeiçoamento do modelo mantém a supervisão viva.
Não existe supervisão que não se meça
Mesmo depois de cumpridas estas três condições, a medição continua a ser necessária.
Há pelo menos três indicadores que devem ser acompanhados. A taxa de rejeição, o tempo médio gasto por decisão e a taxa de acerto posterior das decisões rejeitadas. Se o tempo por decisão tiver descido para a ordem dos segundos, não se está a supervisionar. Se a taxa de rejeição se aproximar de zero, a conclusão é a mesma.
Muito poucas organizações têm resposta quando estes indicadores são pedidos numa auditoria. No entanto, não são medições difíceis, extraem-se de dados que o próprio sistema já produz.
O direito de contestação determina a arquitetura
O artigo 11.º da Lei 6698 reconhece à pessoa o direito de contestar um resultado desfavorável resultante exclusivamente da análise por sistemas automatizados.
A consequência técnica desta disposição é direta. Quando chega uma contestação, tem de ser possível mostrar como a decisão foi tomada. Se não for possível mostrar, não é possível defender a decisão.
Daí resulta esta regra arquitetónica. Num fluxo que produz consequências para uma pessoa não pode usar-se um modelo que não gere justificação. Isto deve ficar escrito desde o início como uma restrição na escolha do modelo. Acrescentar explicabilidade a posteriori não é possível na maioria das arquiteturas.
Registar não basta, é preciso registar a coisa certa
Ao falar de registo de auditoria, o que vem logo à mente é manter um registo, mas o que é determinante é o conteúdo desse registo.
Para que uma decisão possa ser revista mais tarde, é preciso registar em conjunto cinco elementos. Os dados que entraram no sistema, a versão do modelo, o resultado produzido, a justificação em que esse resultado se baseia e a decisão final tomada pela pessoa. Se estes cinco forem mantidos em sistemas separados, depois não podem ser cruzados. Se a versão do modelo não tiver sido registada, meses depois não há forma de responder à pergunta sobre o que o modelo dizia naquela data.
A versão do modelo por registar é, na prática, a lacuna que vejo com mais frequência. O modelo é atualizado, tentam-se explicar decisões antigas com o modelo novo, e não bate certo.
É preciso mostrar a diferença entre certeza e incerteza
Um último ponto. O sistema deve mostrar de forma distinguível o resultado que produz com baixa confiança do que produz com alta confiança.
Se essa distinção não existir, o utilizador confia igualmente em todos e não recebe qualquer aviso precisamente onde o erro é mais provável. No entanto, a incerteza do próprio modelo pode normalmente ser medida. Levar essa medição até à interface é a melhoria mais barata e mais eficaz da supervisão.
Se tivesse de escolher uma única coisa a fazer hoje num projeto de inteligência artificial, seria esta a minha escolha.

## A cláusula mais esquecida num projeto de software: os critérios de aceitação

Fonte: https://kulular.com.tr/pt/publicacoes/contratos-de-desenvolvimento-de-software

Como empresa de software, é um dos primeiros temas de que falamos em cada projeto. Um projeto que começa sem critérios de aceitação escritos é um projeto em que, até ao dia da entrega, cada um espera uma coisa diferente.
Quando se abre um processo de litígio de software, as partes costumam discutir isto. Se o software funciona ou não.
A razão pela qual esta discussão não se resolve não é técnica. No contrato não consta o que significa "funciona". Se não há critério de aceitação, o programador diz que entregou, o cliente diz que não recebeu, e ambos têm razão segundo o seu próprio critério.
Esta única lacuna é o denominador comum dos litígios de software que já vi.
Como deve redigir-se o critério de aceitação
A aceitação é o momento que produz a consequência jurídica da entrega. É também a partir daí que começa a correr o prazo de responsabilidade por defeitos. Ou seja, essa data ser incerta significa que também é incerto quando termina a responsabilidade.
Uma cláusula de aceitação que funciona inclui o seguinte. A lista de testes de aceitação, o ambiente em que o teste será executado, quem o executa, o prazo de objeção e a regra segundo a qual, se não chegar objeção dentro do prazo, a aceitação se considera produzida.
O elemento mais frequentemente esquecido é o ambiente de teste. Um software que funciona na máquina do programador pode não funcionar no ambiente do cliente, e nesse ponto discute-se quem é responsável. Se o ambiente estiver definido no contrato, essa discussão não surge.
Vincular o critério de aceitação à satisfação subjetiva é, por sua vez, a pior opção. Uma aceitação dependente "da satisfação do cliente" cria uma obrigação sem limite de tempo, e o trabalho do programador nunca termina.
Os direitos de propriedade intelectual não passam automaticamente
O segundo erro frequente é a presunção de propriedade. O cliente pensa que, em troca do preço pago, é proprietário do código. Juridicamente, a situação não é essa.
Os programas de computador estão protegidos como obra ao abrigo da Lei n.º 5846, e, salvo estipulação em contrário, os direitos patrimoniais permanecem no titular da obra. A cessão deve ser expressamente regulada, feita por escrito, e os direitos cedidos devem ser enumerados um a um. Uma fórmula geral como "todos os direitos são cedidos" fica em aberto para discussão.
Além disso, há que distinguir três categorias. O código escrito especificamente para o cliente é geralmente cedido. Os componentes preexistentes do programador não são cedidos, são licenciados, e o alcance e a duração da licença são redigidos à parte. Os componentes de código aberto estão sujeitos às suas próprias licenças, e a lista dos utilizados deve constar em anexo ao contrato.
Quando estas três categorias não são distinguidas, acontece o seguinte. O cliente pensa que é proprietário de todo o código, o programador continua a usar a sua própria biblioteca noutro projeto, e o problema só é notado quando surge um litígio.
Um contrato sem gestão de alterações não funciona
Por bem redigido que esteja o texto do âmbito, durante o projeto chegam pedidos de alteração. Se o contrato não disser como esse pedido será tratado, cada pedido transforma-se numa negociação.
Uma regulação que funciona responde a estas perguntas. A quem e de que forma o pedido é comunicado. Por quem e em quantos dias é feita a análise de impacto. Como se calcula o efeito no preço e no calendário. Com a assinatura de quem é dada a aprovação. O que acontece ao pedido não aprovado.
Quando estas cinco perguntas têm resposta, a alteração deixa de ser uma crise e passa a ser um processo.
A qualidade de subcontratante de tratamento surge sem se notar
Se o programador acede a dados pessoais do cliente, passa a ter a qualidade de subcontratante de tratamento nos termos da Lei 6698. Esta qualidade é muitas vezes adquirida sem que ninguém se aperceba.
O caso mais frequente é o uso de dados reais no ambiente de testes. Uma cópia da base de dados de produção é levada para o ambiente de testes, os programadores trabalham com ela, e a partir desse momento nasce uma relação de tratamento de dados. Se o contrato não contiver disposição a esse respeito, a relação decorre sem fundamento jurídico.
A solução mais limpa é não deixar esta situação chegar a existir. Testar com dados mascarados ou sintéticos não é tecnicamente difícil e elimina em grande medida o risco. Se o acesso a dados reais for realmente indispensável, devem regular-se por escrito o objeto, a duração e a finalidade do tratamento, a sujeição do programador a instruções, o recurso a subsubcontratantes, as medidas de segurança e a devolução ou destruição dos dados no final do contrato.
A manutenção é um contrato à parte
Por fim, a manutenção e o suporte. Esta é uma prestação distinta do desenvolvimento e deve ser regulada em separado.
O que é preciso escrever não é o tempo de intervenção, mas a classificação de avarias. Se não se definir qual avaria entra em qual classe, cada avaria é pedida com prioridade máxima. Depois de definidas as classes, o tempo de intervenção e de resolução é escrito separadamente para cada uma.
Há ainda a questão da medição. Um compromisso de nível de serviço que não seja mensurável fica sem sanção quando é violado. Como será feita essa medição e segundo o registo de quem deve constar do contrato.
Quem deve redigir o contrato
Todas estas cláusulas exigem que o direito e a engenharia decidam em conjunto. O advogado não pode redigir sozinho o critério de aceitação, porque não sabe o que é testável. O engenheiro não pode redigir sozinho a cessão de direitos de propriedade intelectual.
A parte que vai para a negociação do contrato sem equipa técnica acaba por aceitar cláusulas que depois não podem ser aplicadas. A cláusula inaplicável, quando surge o litígio, comporta-se como se nunca tivesse existido.

## Um serviço na nuvem no estrangeiro também é transferência de dados

Fonte: https://kulular.com.tr/pt/publicacoes/transferencias-internacionais-de-dados

Ao escolher a infraestrutura de um software, a localização do servidor é muitas vezes discutida em termos de preço e velocidade. Esta escolha tem também uma vertente de transferência de dados, e não é fácil mudá-la depois.
Quando se pergunta a uma organização se transfere dados para o estrangeiro, a resposta costuma ser não. Quando se pergunta depois que serviços utiliza, surge uma lista: alojamento na nuvem, correio eletrónico, software de apoio ao cliente, uma ferramenta de análise, um fornecedor de pagamentos, um serviço de cópias de segurança.
A maioria dos serviços dessa lista não tem servidores na Türkiye. Ou seja, a resposta verdadeira era sim, e a organização não sabia.
Este equívoco vem da própria palavra "transferência", que sugere um ato deliberado: pegar num ficheiro e enviá-lo. Mas manter dados num sistema no estrangeiro, ou fazer com que sejam aí tratados, também é uma transferência. Não é preciso procurar nenhum ato de envio separado.
Ver onde uma transferência começa realmente
O artigo 9.º da Lei turca 6698 regula as transferências para o estrangeiro. A dificuldade na prática não está na norma em si, mas em determinar quando uma transferência ocorreu de facto.
As três situações seguintes originam sempre uma transferência: os dados estarem alojados num servidor no estrangeiro; uma equipa no estrangeiro poder aceder ao sistema para efeitos de apoio; e os dados serem tratados no estrangeiro com o resultado a ser devolvido. A terceira é a mais frequentemente esquecida. Se utiliza um serviço de análise de texto e esse serviço está no estrangeiro, o texto que envia é tratado aí. O resultado voltar não significa que não tenha havido transferência.
O nosso próprio site tem exatamente esta funcionalidade. O campo de texto livre na página inicial envia o texto introduzido para um fornecedor no estrangeiro para análise. É por isso que o nosso aviso de proteção de dados tem uma secção dedicada a isto, e um visitante pode percorrer todo o resto do site sem alguma vez usar esse campo. Garantir que não ocorre nenhuma transferência quando a funcionalidade não é usada foi tanto uma decisão de conceção como a própria funcionalidade.
A coluna em falta no inventário
A maioria dos inventários de dados regista a categoria, a finalidade e o prazo de conservação. A coluna em falta é esta: em que país estão fisicamente estes dados?
Ao acrescentar essa coluna, o quadro muda. Parte dos dados que a organização julgava guardar no seu próprio centro de dados afinal está no estrangeiro. As cópias de segurança são o que mais escapa, porque o serviço de cópias de segurança costuma ser contratado a um fornecedor à parte e ninguém verifica onde está.
Ao elaborar o inventário, é preciso perguntar diretamente ao fornecedor. Se o contrato incluir um compromisso quanto à residência dos dados, deve obter-se por escrito. Se não incluir, o fornecedor pode alterar essa disposição unilateralmente sem que a organização o saiba.
A cadeia de subcontratantes
A segunda camada é ainda menos visível. O fornecedor que utiliza pode, por sua vez, depender de outros fornecedores para a sua própria infraestrutura.
Usa um software de apoio ao cliente; esse software funciona sobre um fornecedor de nuvem; esse fornecedor usa um serviço distinto para a pesquisa; e liga-se a um terceiro para enviar notificações. Os seus dados circulam por toda essa cadeia.
Não é possível controlar essa cadeia por completo, mas é possível torná-la visível. O contrato deve exigir a notificação do uso de subcontratantes e conferir o direito de se opor a uma alteração. A maioria dos fornecedores empresariais já oferece isto, só é preciso pedir.
O que fazer
O primeiro passo é elaborar um inventário de serviços: o nome de cada serviço externo utilizado, para que serve, a que categorias de dados pessoais pode aceder e onde estão os seus servidores.
Feita essa tabela, há três opções: substituir o serviço por uma alternativa alojada na Türkiye, mudar para a região turca do fornecedor, se este a tiver, ou dar à transferência uma base jurídica adequada através de um dos mecanismos previstos na lei.
As três têm um custo, e a escolha certa depende da natureza do trabalho. Mas não escolher nenhuma delas, ou seja, nem sequer se ter apercebido da situação, é a opção mais cara, porque isso significa também que o aviso de proteção de dados está a dar informação incorreta, e uma única lacuna acaba por violar duas obrigações ao mesmo tempo.
As regras nesta área continuam a evoluir, e as decisões do Conselho redesenham o quadro de vez em quando. Convém rever a situação atual antes de escolher um mecanismo de transferência.

## 72 horas numa violação de dados: para onde vai o tempo do lado do software

Fonte: https://kulular.com.tr/pt/publicacoes/notificacao-de-violacao-de-dados

A notificação de violações é apresentada como um processo jurídico. Mas quanto deste prazo se perde é determinado pela forma como o sistema foi concebido, meses antes do incidente.
Um alerta chega à mesa de uma organização numa segunda-feira de manhã: foi detetado um acesso invulgar num servidor. A partir desse momento, o relógio das setenta e duas horas começa a correr.
Setenta e duas horas parece muito tempo. O que se segue é um relato hora a hora de para onde vai realmente esse tempo, porque sem ver essa repartição é difícil perceber por que razão a preparação para uma violação tem de ser feita meses antes, não durante ela.
As primeiras oito horas: será mesmo uma violação?
A primeira tarefa é determinar se o alerta é real. Pode ser um falso positivo, uma operação de manutenção ou uma permissão mal configurada.
Nesta fase, a equipa técnica analisa os registos. Se os registos não forem suficientemente bons, e na maioria das organizações não são, isto arrasta-se. Sem saber que conta acedeu a que tabela a partir de que endereço, não é possível dar nenhum passo seguinte.
O primeiro ponto crítico é este. Quem não mantém registos vê o relógio esgotar-se aqui, e esse tempo nunca mais se recupera.
As vinte e quatro horas seguintes: que dados foram afetados
Uma vez estabelecido que se trata de uma violação, surge uma única pergunta. Que dados pessoais existiam nesse servidor?
Uma organização com um inventário atualizado responde a isto em dez minutos. Uma que não o tenha tenta descobrir examinando o esquema da base de dados, verificando nomes de tabelas, extraindo registos de amostra, perguntando aos programadores. Só isso pode facilmente levar um dia inteiro.
A segunda metade da pergunta é mais difícil. O que existe nas cópias de segurança? Existe uma cópia que foi exportada para um relatório? Foi carregada uma amostra num ambiente de testes? Se as respostas não estiverem escritas em lado nenhum, acabam por assentar em suposições, e uma notificação baseada em suposições acaba por ter de ser corrigida depois.
As doze horas seguintes: quantas pessoas são afetadas
Uma vez delimitado o âmbito, é preciso produzir um número. Quantos titulares, que categorias de dados, que zonas geográficas.
Um erro frequente aqui é arredondar o número. Dizer "aproximadamente dez mil pessoas" não leva à rejeição da notificação, mas se mais tarde surgir um número real bem diferente, isso prejudica a credibilidade do que a organização declarou. Se não for possível obter um número exato, é melhor dizê-lo assim, e explicar porquê, do que arriscar um.
O tempo restante: preparar e enviar a notificação
A notificação ao Conselho deve cobrir quando e como ocorreu a violação, que categorias de dados foram afetadas, as suas possíveis consequências e as medidas tomadas e previstas.
Redigir isso a partir de uma página em branco consome o tempo que resta. Uma organização com um modelo já pronto preenche-o em meia hora. Quem está autorizado a assiná-la também deve ser decidido antecipadamente, porque se essa discussão começar nesta fase, não há tempo para ela.
Notificar as pessoas afetadas é uma tarefa à parte. Faz-se assim que for razoavelmente possível depois de identificadas as pessoas afetadas; se o contacto direto não for possível, recorre-se a outro meio adequado. A linguagem importa aqui. Uma mensagem enterrada em detalhe técnico impede que a pessoa perceba o que realmente tem de fazer.
O que o plano tem mesmo de conter
A lição deste percurso é esta. O valor de um plano de resposta a incidentes está em ter-se pensado antecipadamente no que é preciso pensar no momento do incidente.
Precisa de uma repartição clara de funções. Quem delimita o incidente, quem decide que é uma violação, quem assina. Um plano que depende de uma única pessoa cai no dia em que essa pessoa está ausente.
Precisa de um limiar definido. O que se considera violação deve estar escrito antecipadamente; caso contrário, essa discussão acontece dentro das setenta e duas horas.
Precisa de uma regra de preservação de provas. O primeiro instinto costuma ser limpar os sistemas afetados, o que torna impossível uma investigação adequada. O plano deve dizer explicitamente que os registos são mantidos intactos.
Precisa de modelos de comunicação já preparados, tanto para o Conselho como para os titulares afetados.
Nada termina quando a notificação é enviada
A notificação não é o fim da obrigação. O Conselho avalia se as medidas técnicas e organizativas adotadas foram suficientes.
Uma violação que se repete na mesma organização é interpretada como prova de que essas medidas não eram suficientes. Por isso, a ação corretiva adotada após uma violação deve ficar registada e o seu efeito deve ser medido. A frase "foram tomadas as medidas necessárias" não é, por si só, prova de nada.
A única coisa que vale a pena fazer hoje
O mais rentável que se pode fazer antes de sofrer uma violação é elaborar o inventário juntamente com a localização física dos dados: que base de dados, que tabela, que campo e que cópia de segurança contém cada dado.
Se essa tabela existir, cerca das primeiras trinta das setenta e duas horas ficam efetivamente recuperadas. Se não existir, por bem redigido que esteja o plano, o tempo não vai chegar.

## Porque é que a informação aos titulares deve corresponder ao esquema da base de dados

Fonte: https://kulular.com.tr/pt/publicacoes/redigir-um-aviso-de-privacidade

Este artigo começa com um texto jurídico, mas a origem do problema está no software. O sítio que mostra com mais rigor que dados uma organização recolhe é o esquema da base de dados da aplicação que usa. Se a informação aos titulares não corresponde a esse esquema, a correção deve muitas vezes começar pelo sistema e não pelo texto.
Quando reviso o aviso de proteção de dados de uma organização, a primeira coisa que faço não é lê-lo. É pegar nas categorias de dados que o aviso enumera e compará-las com o esquema da base de dados.
Essa comparação dá quase sempre o mesmo resultado: há campos que o aviso não menciona. Por vezes acontece o contrário, categorias que o aviso enumera mas que o sistema nunca chega a recolher. Ambos os casos apontam para o mesmo problema de fundo. O aviso foi elaborado a partir de um modelo, não de uma verificação real dos factos.
O dever não é elaborar um documento
O artigo 10.º da Lei 6698 exige que o responsável pelo tratamento, ao recolher dados pessoais, comunique determinados elementos: a sua identidade, a finalidade do tratamento, os destinatários a quem os dados serão transferidos e porquê, o método de recolha e a base jurídica, além dos direitos previstos no artigo 11.º.
O verbo-chave aqui é comunicar. O documento é um veículo; o dever consiste em dar informação exata. Um aviso que dá informação inexata é pior do que não ter aviso nenhum, porque a organização já fez uma declaração que não corresponde à realidade.
Por isso, redigir o aviso tem de vir depois do inventário, não antes. Uma organização com inventário escreve o aviso num dia. Uma sem inventário escreve-o sem saber realmente sobre o que está a escrever.
Os cinco erros que mais vejo
Há anos que vejo os mesmos erros, e nenhum deles resulta de falta de conhecimento jurídico.
Fundir o aviso e o consentimento expresso numa única caixa de verificação. O utilizador marca "li e aceito" e é considerado simultaneamente informado e a prestar consentimento. O aviso é uma comunicação, não algo que se aceita. Esta fusão enfraquece o carácter do consentimento como declaração de vontade autónoma.
Mostrar o aviso depois de a operação já estar concluída. O formulário é enviado e só depois surge um link para o aviso numa página de agradecimento. Nessa altura os dados já foram recolhidos.
Forçar um único aviso a cobrir todos os processos. Recrutamento, contacto com clientes, relação com fornecedores e visitas ao site são todos reunidos num só documento. O resultado é um aviso geral que não descreve com rigor nenhum deles.
Não indicar a base jurídica, ou enumerá-las todas de uma vez. Uma frase como "nos termos das condições previstas nos artigos 5.º e 6.º" não indica base jurídica nenhuma. Deve escrever-se aquela de que depende realmente cada tratamento concreto.
Não indicar o prazo de conservação. O Comunicado espera que isto conste da informação dada ao titular dos dados, e sem essa indicação o titular não tem forma de saber durante quanto tempo os seus dados serão conservados.
Como o aviso deve ser estruturado
Um bom aviso é redigido processo a processo. Não começa com "a nossa empresa trata os seus dados pessoais", começa com "quando preenche o formulário de contacto, são tratados os seguintes dados".
Elaborar uma tabela de quatro colunas para cada processo facilita muito acertar: categoria de dados, finalidade do tratamento, base jurídica, prazo de conservação. Com essa tabela pronta, o aviso praticamente se escreve sozinho, e quem o lê consegue encontrar o que procura.
A linguagem também importa. O Comunicado exige que a informação seja transmitida de forma clara, compreensível e simples. Na prática, vemos o contrário. Os avisos alongam-se, as frases tornam-se pesadas e o resultado deixa de se ler. Um aviso que ninguém lê não cumpre a sua função de comunicação. Simplificá-lo não é aqui uma questão de estilo, é o que o dever exige.
Manter o aviso atualizado
Um aviso de proteção de dados não é um documento que se escreve uma vez e se esquece. Quando se adiciona um novo campo, se começa a trabalhar com um novo fornecedor ou se introduz uma nova transferência, o aviso também precisa de ser atualizado.
A única forma sustentável de o conseguir é ligar a atualização ao próprio processo de desenvolvimento. Uma alteração que acrescenta um novo campo de dados pessoais ao modelo de dados deve desencadear também a atualização do inventário e do aviso. Sem essa ligação, o aviso afasta-se da realidade já no primeiro ano, sem que ninguém dê por isso.
Foi assim que construímos essa ligação no nosso próprio site. Quando adicionámos a funcionalidade de análise assistida por inteligência artificial, entrou ao mesmo tempo no aviso uma secção própria a explicar a transferência internacional. A funcionalidade não foi publicada sem ela. Deve ser essa a ordem.

## Software conforme à KVKK: começar pelo inventário de dados

Fonte: https://kulular.com.tr/pt/publicacoes/conformidade-com-a-kvkk

As organizações chegam muitas vezes até nós a dizer que querem um software conforme à KVKK. Para ver onde começa essa conformidade no código, é preciso olhar primeiro para o inventário, porque sem saber que dados estão guardados e onde, não se consegue definir corretamente nem as regras de acesso nem os prazos de conservação.
Quando se vai a uma organização para um trabalho de conformidade com a KVKK, encontra-se geralmente o seguinte. Um aviso de proteção de dados, um formulário de consentimento expresso, uma política de conservação e destruição. Os três estão preparados, assinados, arquivados.
Depois faz-se uma única pergunta. De onde vieram as categorias de dados indicadas nestes textos?
A resposta é normalmente esta. Foi tirado um modelo encontrado na internet, escreveu-se o nome da organização, acrescentaram-se alguns pontos. Ou seja, a declaração não resultou da verificação da realidade, mas de um modelo. Este é o erro de ordem mais frequente e mais dispendioso que vejo nos trabalhos de conformidade.
Por que razão a ordem é tão importante
O aviso de proteção de dados é uma declaração. O artigo 10.º da Lei exige que o responsável pelo tratamento comunique as categorias de dados tratados, as finalidades, os destinatários a quem serão transferidos e a base jurídica. Se se faz uma declaração, essa declaração tem de ser exata.
Um texto redigido sem elaborar o inventário não pode ser exato. Na melhor das hipóteses, será incompleto. Quando numa auditoria se deteta uma atividade de tratamento que não consta do texto, não existe apenas uma lacuna técnica, existe um incumprimento do dever de informar de forma adequada.
O inverso também é verdade. Uma organização que já dispõe do inventário redige o aviso de proteção de dados num dia, porque tudo o que há a escrever já está determinado.
O que se procura realmente no inventário
A tabela de inventário costuma elaborar-se com as colunas categoria de dados, finalidade e prazo de conservação. Estas três colunas não bastam.
A coluna em falta é esta. Onde está este dado fisicamente? Em que base de dados, em que tabela, em que campo? Existe também nas cópias de segurança? Existe uma cópia no sistema de um fornecedor terceiro?
Quando esta pergunta não é feita, o inventário reflete a opinião que a organização tem de si própria, não a realidade. Quando ocorre uma violação de dados, a primeira pergunta será "que dados pessoais existiam nesse servidor". Um inventário que não indica a localização física é inútil nesse momento.
A escolha da base jurídica é uma decisão arquitetónica
O artigo 5.º da Lei enumera as condições de tratamento. Na prática, este artigo é muitas vezes tratado como uma formalidade, mas a base jurídica escolhida determina diretamente como o sistema deve ser construído.
Numa atividade de tratamento baseada no consentimento expresso, o consentimento pode ser retirado a qualquer momento. No momento em que é retirado, o tratamento tem de cessar. Isto exige três coisas no sistema. Um registo da versão do texto a que o consentimento foi dado, uma interface que dê ao utilizador a possibilidade de o retirar, e um controlo que interrompa o tratamento correspondente quando o consentimento é retirado. Faltando qualquer uma destas três, basear-se no consentimento coloca a organização numa posição indefensável.
Em contrapartida, um tratamento necessário para a execução de um contrato não exige estes mecanismos. O mesmo dado, tratado com base jurídica diferente, gera um encargo técnico completamente distinto. Por isso, a escolha da base jurídica não deve ser feita pelo advogado sozinho, à margem da arquitetura.
O prazo de conservação e o componente que o aplica
Fixar um prazo de conservação é a parte mais fácil do trabalho de conformidade. Garantir a sua aplicação é a parte mais difícil.
Uma conceção que funciona tem este aspeto. Cada registo transporta o seu próprio prazo de conservação, por exemplo um campo fim_conservacao. Um processo percorre periodicamente os registos cujo prazo expirou. Esse processo apaga, destrói ou anonimiza o registo e regista a operação feita numa tabela à parte. O que se apresenta numa auditoria não é o texto da política, é essa tabela.
As organizações que não constroem esta estrutura fazem geralmente o seguinte. Escrevem o prazo na política, adiam a aplicação para uma data posterior, e essa data nunca chega. Passados dois anos, encontram-se dados não apagados e um documento que diz que deveriam ter sido apagados. A coexistência destas duas coisas é pior do que nunca ter escrito política nenhuma.
VERBİS e a questão do âmbito
A obrigação de registo no Registo dos Responsáveis pelo Tratamento está sujeita a critérios fixados pelo Conselho. O número anual de trabalhadores, a dimensão do balanço financeiro e a natureza dos dados tratados são determinantes.
Aqui é preciso um alerta. O âmbito da isenção mudou ao longo do tempo por via de decisões do Conselho e pode continuar a mudar. Uma organização isenta hoje fica obrigada quando o número de trabalhadores aumenta. Por isso, a isenção não é algo que se determina uma vez e se esquece, deve ser verificada anualmente. Para os limiares atuais é preciso consultar os comunicados publicados pela Autoridade.
O plano de violação é redigido antecipadamente
O parágrafo quinto do artigo 12.º da Lei exige que a violação seja notificada ao Conselho o mais rapidamente possível. As decisões do Conselho concretizaram esse prazo em setenta e duas horas.
Setenta e duas horas é o tempo total atribuído, depois de detetado o incidente, para determinar o seu âmbito, identificar as pessoas afetadas e preparar a notificação. Mesmo o primeiro destes passos demora dias na maioria das organizações, porque não está escrito onde cada dado é guardado.
Ou seja, a preparação para uma violação começa muito antes de esta ocorrer, e desemboca de novo no mesmo ponto. O inventário.
O que acontece quando a conformidade termina
Não termina. Uma nova funcionalidade gera um novo campo de dados. Um novo fornecedor gera uma nova transferência. As decisões do Conselho estreitam o quadro.
Por isso, em vez de conceber a conformidade como um projeto, é preciso incorporá-la no próprio processo de desenvolvimento do produto. Se a atualização do inventário ao acrescentar um novo campo passar a fazer parte da revisão de código, o processo sustenta-se a si próprio. Caso contrário, recomeça-se do zero todos os anos e repete-se sempre o mesmo erro de ordem.

## Software de tecnologia jurídica precisa de mais do que gerar documentos

Fonte: https://kulular.com.tr/pt/publicacoes/tecnologias-juridicas

As tecnologias jurídicas são uma das cinco áreas em que desenvolvemos software. O equívoco mais frequente nesta área é procurar o valor do produto no documento que gera. O valor real está em a regra funcionar sempre da mesma forma dentro do sistema.
Ao olhar para a apresentação de um produto de tecnologia jurídica, é muito provável que veja o seguinte. Gera minutas de contratos, propõe cláusulas, formata o documento. São tarefas úteis. O problema é que a verdadeira questão da área não é essa, e o problema que julgamos que estas ferramentas resolvem é, na realidade, a parte mais fácil do problema.
A verdadeira questão está aqui. Uma organização está sujeita a uma obrigação jurídica. Faz-se uma interpretação sobre o que significa essa obrigação. A interpretação é escrita num documento. Depois esse documento é arquivado, e o funcionamento diário da organização continua sem conhecimento desse documento. Esta desconexão entre o documento e o sistema é o erro mais dispendioso que vejo na prática, e nenhuma ferramenta de modelos de contratos o resolve.
Interpretar é tarefa da pessoa, aplicar é tarefa do sistema
Transformar uma regra em software não é escrever a regra em código. Entre as duas coisas existe um passo que não pode ser automatizado.
O artigo 7.º da Lei 6698 estabelece que, quando desaparecerem as razões que exigiam o seu tratamento, o dado pessoal será apagado, destruído ou anonimizado. Esta disposição é clara. Mas o que significa exatamente "o desaparecimento da razão" quanto aos dados de faturação de uma organização? O fim da relação com o cliente, o termo do prazo de conservação previsto na legislação fiscal, ou o que ocorrer mais tarde entre os dois? A esta pergunta responde um jurista. A resposta dada é uma interpretação, e enquanto essa interpretação não ficar registada, dentro de seis meses ninguém se lembrará de por que razão se escolheu aquele prazo.
É aqui que começa o trabalho do software. Depois de dada a interpretação, garantir que ela é aplicada sempre da mesma forma e que essa aplicação pode ser demonstrada. Se dispõe de um sistema que faz isto, está a usar tecnologia jurídica. Se apenas gera modelos, está a usar um processador de texto.
O que acontece quando o documento e o sistema se separam
Vejamos um exemplo concreto. Na política de conservação de uma organização consta que os registos de comunicação com clientes serão conservados durante dois anos. Quando chega uma auditoria, essa política é apresentada.
O auditor faz uma única pergunta. Que componente aplica este prazo?
A resposta, na maior parte das vezes, não existe. Na base de dados há um campo created_at, mas não há expires_at. Não existe nenhum processo que apague o registo quando o prazo termina. Mesmo que a eliminação ocorra, não produz qualquer registo do que foi feito. No final, a organização não consegue demonstrar que faz o que a sua política diz. A própria política não é prova, é quando muito uma declaração de intenções.
A forma de corrigir este quadro não é escrever um melhor texto de política. É acrescentar ao modelo de dados um campo que transporte o prazo de conservação, escrever um componente que aplique esse prazo, e garantir que esse componente produz um registo quando é executado. Quando as três coisas existem em conjunto, o texto da política deixa de ser uma afirmação e passa a ser a descrição daquilo que o sistema efetivamente faz.
Os cinco elos da cadeia
A transformação de um texto jurídico num controlo que funciona no sistema ocorre em cinco passos. A ordem destes passos é importante, e a omissão de qualquer um deles torna o resultado pouco fiável.
Primeiro identifica-se a norma. Determina-se a regra aplicável e, se existir, a sua exceção. Depois faz-se a interpretação, ou seja, decide-se o que a regra significa no processo de negócio concreto. Este passo é da responsabilidade da pessoa e deve ficar registado. No terceiro passo, a interpretação é ligada à arquitetura, determinando-se que campo transportará que regra. No quarto passo escreve-se o componente que aplica a regra no momento da operação. No quinto passo regista-se a execução desse componente.
Um controlo escrito sem a interpretação prévia aplica a regra errada. Um controlo que não produz prova não serve numa auditoria. O erro que encontro com frequência é saltar o terceiro e o quarto passo e avançar diretamente para o quinto. A organização mantém um registo, anota ali algo, mas não é claro que regra esse registo demonstra ter sido aplicada.
A questão do monopólio da advocacia
Existe um limite que qualquer pessoa que desenvolva produtos nesta área deve conhecer. O artigo 35.º da Lei da Advocacia n.º 1136 reserva aos advogados o acompanhamento de assuntos jurídicos e a emissão de pareceres jurídicos.
Na prática, isto determina o que o seu produto pode e não pode dizer. Dizer "falta esta cláusula no seu contrato" é informar. Dizer "não assine este contrato, terá consequências contra si" é emitir um parecer. A linha entre as duas coisas é fina e deve ser conscientemente preservada na conceção do produto. O método mais sólido para preservar essa linha é o sistema não tomar a decisão por si próprio e manter visível, atrás de cada resultado, uma decisão humana.
Este limite parece um obstáculo, mas é na realidade uma boa restrição de conceção. Um sistema que não assume a decisão também não assume a responsabilidade quando comete um erro, e isso impede que o utilizador confie cegamente no sistema.
O que a inteligência artificial mudou e o que não mudou
O processamento de linguagem natural traz um ganho real de eficiência na análise de documentos. Encontrar um determinado tipo de cláusula entre centenas de contratos era antes um trabalho de semanas. Agora demora horas.
O que não muda é a responsabilidade. Se não for possível rastrear de que documento e de que parágrafo provém o resultado produzido pelo modelo, esse resultado não é uma constatação, é uma suposição. Do mesmo modo, se o sistema não mostrar de forma distinguível um resultado de que não está seguro face a um de que está, o utilizador confia igualmente em todos eles, e o erro passa despercebido.
Quando estas duas condições não são cumpridas, o ganho de eficiência obtido é depois compensado pelo risco que surge. E o pior é que não se sabe quando esse risco se concretizará.
Por onde começar
Ao iniciar um projeto corporativo de tecnologia jurídica, recomendo escolher uma única obrigação. Abordá-las todas de uma vez soa bem, mas na prática nenhuma delas chega a concluir-se.
Para a obrigação escolhida constroem-se os cinco elos na íntegra. Redige-se a norma, a interpretação fica registada, liga-se ao modelo de dados, o controlo funciona, produz-se a prova. Este trabalho conclui-se em seis semanas, e no final não terá um relatório, mas um controlo a funcionar e um registo que pode ser mostrado numa auditoria.
A segunda obrigação avança muito mais depressa. Porque a parte difícil não é a regra, é construir a cadeia pela primeira vez.

## A responsabilidade do Estado nas startups de tecnologia espacial

Fonte: https://kulular.com.tr/pt/publicacoes/direito-espacial

Para equipas que tratam dados de satélite ou desenvolvem software para startups espaciais, esta regra parece distante. Mas influencia muitas decisões, desde a forma de guardar os dados até à forma de estruturar o contrato.
No direito espacial existe uma única regra que funciona de forma diferente da de todos os outros ramos do direito, e a maioria dos empreendedores descobre-a tarde demais.
O artigo 6.º do Tratado do Espaço Exterior de 1967 estabelece que os Estados são internacionalmente responsáveis pelas atividades espaciais nacionais. O resultado não muda ainda que a atividade seja conduzida por uma empresa privada. O artigo acrescenta ainda que essas atividades ficam sujeitas à autorização e à supervisão contínua do Estado em causa.
É mais fácil perceber o que isto significa com um exemplo. Quando uma empresa de software comete um erro, responde perante o seu cliente. Quando uma empresa espacial comete um erro, é o Estado que passa a responder perante outro Estado. A diferença não é de escala, é de natureza.
Como se constrói a cadeia de responsabilidade
A Convenção sobre Responsabilidade de 1972 concretiza esta cadeia. Por danos causados na superfície da Terra ou a uma aeronave em voo, o Estado de lançamento tem responsabilidade objetiva. Ou seja, não se exige culpa.
Isto produz uma consequência direta no plano comercial. O Estado vai querer transferir para o operador privado esta responsabilidade que sobre ele pode recair. Por isso o documento de autorização costuma conter cláusulas de sub-rogação, obrigação de seguro e requisitos de garantia. Se, ao começar a negociar o contrato, não souber o valor destas rubricas, também não sabe o custo real do projeto.
O registo está ligado a isto. A Convenção sobre Registo de 1975 prevê a inscrição de objetos lançados para o espaço. O registo determina sob a jurisdição e o controlo de que Estado se encontra um objeto. Ou seja, é aqui que começa a resposta à pergunta sobre qual o direito aplicável.
O mapa de autorização na Turquia
A Agência Espacial Turca foi criada em 2018 por Decreto Presidencial e é responsável pela elaboração do programa espacial nacional e pela coordenação das atividades.
Mas a atividade espacial não se limita a um único organismo. O uso de frequências e órbitas está sujeito a um regime próprio, no qual são determinantes os regulamentos da União Internacional de Telecomunicações. A nível nacional, a autoridade competente é o organismo turco de tecnologias da informação e comunicação. Se estiver em causa o controlo de exportações, entram em jogo outras entidades.
Ao iniciar um projeto, é preciso elaborar este mapa. Que autorização se obtém junto de que organismo, por que ordem e em quanto tempo. Este calendário avança de forma independente do calendário de desenvolvimento técnico e costuma ser mais longo do que ele. O que atrasa o projeto muitas vezes não é o software, é a autorização.
Os próprios dados são uma questão à parte
O problema prático que mais frequentemente encontro em projetos espaciais não é técnico, tem a ver com os dados.
Os direitos sobre os dados da missão devem ser regulados nos contratos de lançamento e de operação. Se ficar uma lacuna no contrato, resolvê-la depois é muito difícil, porque a contraparte já teve acesso a esses dados e uma limitação retroativa não funciona na prática.
Os dados de observação da Terra colocam uma questão à parte. Com o aumento da resolução, reforça-se a probabilidade de o dado adquirir a natureza de dado pessoal. Uma imagem em que se consegue ler a matrícula de um veículo não está sujeita ao mesmo regime que uma imagem à escala de uma cidade. Ao conceber o sistema, deve determinar-se a partir de que resolução entra em jogo um regime de tratamento diferente, e isto deve ser construído como um ponto de controlo na própria linha de dados.
O terceiro ponto é a integridade. Deve poder demonstrar-se a origem do dado de telemetria, a sua marca temporal e que não foi alterado. É a única coisa que terá valor probatório quando se fizer uma análise posterior a um incidente. Se existir a possibilidade de o registo ter sido gerado a posteriori, o próprio registo não serve como defesa.
O debate sobre a extração de recursos
O artigo 2.º do Tratado proíbe a apropriação nacional. A situação da extração de recursos de corpos celestes face a esta proibição não é clara.
Alguns Estados adotaram, na sua legislação interna, normas que reconhecem propriedade sobre o recurso extraído. A compatibilidade destas normas com o Tratado é discutida, e ainda não se consolidou uma prática internacional assente sobre a matéria. O que se pode dizer honestamente a um empreendimento que atue nesta área é o seguinte. O terreno jurídico não está consolidado, e essa incerteza deve ser registada como uma rubrica de risco na decisão de investimento. Qualquer opinião apresentada como certa dá, à data de hoje, uma informação incompleta.
O que levar para a mesa de negociação do contrato
Nos projetos espaciais, vejo o mesmo problema sempre que a equipa técnica e a equipa jurídica trabalham em separado. As decisões tomadas ao escrever o software do segmento terrestre afetam diretamente o regime de responsabilidade, e essa ligação costuma ser notada só depois de o contrato estar assinado.
À primeira negociação devem chegar já esclarecidos estes três pontos. De que organismo e em que condições será obtida a autorização. Como será repartida entre as partes a responsabilidade e o encargo do seguro. A quem pertencerão os direitos sobre os dados da missão e quem poderá aceder-lhes. O planeamento técnico feito sem resolver estes três pontos acaba por ter de ser refeito depois.

## Quando é que um software de saúde é considerado dispositivo médico

Fonte: https://kulular.com.tr/pt/publicacoes/direito-da-saude

Para uma equipa que desenvolve software de saúde, a resposta a esta pergunta muda o prazo e o custo do projeto. O mesmo código pode ter um peso de conformidade muito diferente consoante a forma como o produto é definido.
Imagine duas aplicações. Ambas recolhem os sintomas introduzidos pelo utilizador, executam um algoritmo e devolvem uma lista. O código é quase idêntico. Uma está sujeita à regulamentação sobre dispositivos médicos, a outra não.
O que faz a diferença é o texto descritivo na loja de aplicações. A primeira diz "dá informação sobre possíveis situações com base nos seus sintomas". A segunda diz "avalia os seus sintomas e mostra o diagnóstico provável". Esta segunda frase transforma o produto num produto apresentado com fins de diagnóstico, e com isso entram em jogo a classificação de risco, a avaliação da conformidade, o processo técnico, a avaliação clínica e as obrigações de vigilância pós-comercialização.
Este é o erro mais dispendioso e mais facilmente evitável que vejo em projetos de tecnologia de saúde. A descrição do produto é escrita pela equipa de marketing, ninguém pensa na sua consequência jurídica, e o produto acaba a entrar num regime de conformidade que nunca se pretendeu assumir.
A finalidade de uso é um texto jurídico
A regra prática que daqui resulta é a seguinte. A descrição do produto deve ser redigida com o mesmo cuidado que uma política de privacidade e passar por uma revisão jurídica antes de ser publicada.
Essa revisão não deve limitar-se à descrição da loja. O título no site, a frase no vídeo promocional, a afirmação na apresentação comercial e o texto no documento de apoio podem produzir o mesmo resultado. Se num sítio disse "diagnostica", escrever noutro "é apenas informativo" não retira essa declaração.
A decisão tem de ser tomada desde o início. Se o produto vai ser um dispositivo médico, o processo exigido por esse regime é montado desde o início e entra no plano como uma rubrica de custo. Se não vai ser, manter esse limite em cada texto deve tornar-se uma regra de desenvolvimento do produto.
A arquitetura de acesso aos dados de saúde
O artigo 6.º da Lei 6698 considera os dados de saúde como categoria especial de dados pessoais e sujeita o seu tratamento a condições mais restritas. A tradução técnica desta qualificação fica incompleta na maioria dos projetos.
O quadro que vejo com frequência é este. A aplicação funciona, os dados são guardados, mas no sistema toda a gente pode ver tudo. O programador consegue aceder à base de dados de produção, a equipa de apoio consegue abrir o registo do paciente, a pessoa gestora consegue ver dados em bruto nos relatórios. Isto significa que o acesso não está limitado, e é difícil de defender numa auditoria.
A configuração correta começa pelo controlo de acesso baseado em funções, mas não termina aí. Cada acesso deve ficar registado, esse registo deve mostrar quem o fez e com que finalidade, e um acesso fora do habitual deve poder ser detetado. Se alguém abre o registo de um paciente a meio da noite, isso tem de ser visível no sistema.
O ambiente de testes é uma questão à parte. Testar com dados reais de pacientes é o hábito mais comum e mais arriscado na tecnologia de saúde. Trabalhar com dados mascarados ou sintéticos elimina em grande medida esse risco e não é tecnicamente difícil de implementar.
Apoio clínico à decisão e responsabilidade
Os sistemas de apoio à decisão com inteligência artificial levantam a questão de quem é responsável. Na prática, a configuração segura é a de o sistema produzir uma recomendação e a decisão final ficar a cargo do profissional de saúde competente.
Para que esta configuração não fique apenas no papel, é preciso manter em conjunto três registos. A recomendação produzida pelo sistema, os dados em que essa recomendação se baseia, e a decisão final tomada pelo profissional de saúde. Se os três forem guardados separadamente, não podem depois ser cruzados; se não forem guardados de todo, não é possível demonstrar onde está a responsabilidade.
Vale a pena acrescentar aqui um indicador. Deve acompanhar-se a taxa com que o profissional de saúde rejeita a recomendação do sistema. Se essa taxa se aproximar de zero, a supervisão humana tornou-se formal, e nesse ponto é de facto o sistema que toma a decisão. Esta constatação pode ser determinante numa discussão de responsabilidade.
Os serviços de saúde à distância
Os serviços de saúde à distância são regidos pela regulamentação do Ministério da Saúde. Que serviços podem ser prestados à distância, as obrigações de registo e os limites do serviço são definidos em regulamentação secundária. Como essa regulamentação pode mudar ao longo do tempo, ao conceber o produto é preciso consultar o texto em vigor.
O princípio que não muda é este. As situações que exigem observação presencial não podem ser resolvidas à distância. Uma aplicação de saúde à distância deve conseguir reconhecer e reencaminhar um pedido que exceda esse limite. O sistema conseguir dizer "para esta situação, consulte por favor um médico" não é uma funcionalidade de usabilidade, é uma exigência jurídica.
Ao iniciar um projeto
Nos projetos de tecnologia de saúde, a pergunta que tem de ter resposta na primeira reunião não é o que o produto vai fazer, mas o que vai declarar que é. Cada linha de código escrita sem esta pergunta ter resposta pode ter sido escrita segundo o regime errado.
A segunda pergunta diz respeito ao modelo de dados. Que dado é realmente necessário, quem poderá vê-lo, onde será registado o acesso e o que acontecerá quando a finalidade terminar. A resposta a estas quatro perguntas determina diretamente o desenho das tabelas, e alterá-lo depois, por exigir migrar dados de pacientes já existentes, gera um problema tanto técnico como jurídico.

## Câmara obrigatória em software de exames à distância e proporcionalidade

Fonte: https://kulular.com.tr/pt/publicacoes/direito-da-educacao

Para uma equipa que desenvolve software de exames à distância, esta pergunta parece uma escolha técnica. Ligar a câmara ou não, gravar ou não. Na verdade, é uma decisão de conceção que determina que dados o produto vai tratar, e é cara de mudar depois.
Um estudante recusa-se a ligar a câmara num exame à distância e explica que não quer que a sua casa seja gravada. A instituição responde que a integridade do exame tem de ser garantida. Neste ponto chocam dois interesses legítimos, e a questão não é qual deles tem razão, mas se o método escolhido pela instituição é realmente necessário.
Esta pergunta surge-me constantemente em projetos de tecnologia educativa, e costuma ser discutida num enquadramento errado. O debate transforma-se no dilema "liga-se a câmara ou não", quando a pergunta que juridicamente há que fazer é mais estreita. Consegue-se alcançar o mesmo fim tratando menos dados?
O que pergunta a proporcionalidade
O artigo 4.º da Lei 6698 exige que os dados pessoais sejam pertinentes, limitados e proporcionais relativamente às finalidades para que são tratados. Este princípio não é um desejo abstrato, é um instrumento de filtragem concreto.
A integridade do exame é uma finalidade legítima, quanto a isso não há discussão. Mas essa finalidade não legitima qualquer dado que possa ser recolhido sobre o candidato. Gravação de vídeo contínua, captura de ecrã, monitorização dos movimentos do teclado e do rato, instalação de um cliente que exige permissões alargadas no dispositivo. Cada um destes elementos deve ser avaliado separadamente, e para cada um deve perguntar-se: a integridade do exame não pode ser garantida sem isto?
Na maioria dos casos, pode. Aleatorizar o banco de perguntas, fixar um limite de tempo, baralhar a ordem das perguntas, aumentar o peso das perguntas abertas e uma análise estatística posterior de anomalias conseguem um nível sério de integridade sem necessidade de gravação. Avançar diretamente para a gravação por câmara sem experimentar antes estas ferramentas é uma escolha difícil de defender do ponto de vista da proporcionalidade.
Por que razão o consentimento não funciona aqui
O primeiro reflexo das instituições é pedir o consentimento do estudante. Antes de o exame começar aparece uma caixa de aceitação, e o estudante não pode entrar no exame sem a marcar.
O problema desta construção é o seguinte. Para que o consentimento seja válido, tem de ter sido dado com vontade livre. É difícil sustentar que o consentimento de um estudante que, sem aceitar, não pode fazer o exame, assenta numa vontade livre. E, além disso, do outro lado está a instituição que dá a nota, regista a assiduidade e influencia a decisão de graduação. Esse desequilíbrio de poder vicia o consentimento desde o início.
A conclusão prática que daqui resulta é a seguinte. Basear-se no consentimento quanto aos dados dos estudantes dá à instituição uma sensação de segurança, mas não proporciona proteção jurídica. O que a instituição deve fazer é avaliar se o tratamento assenta noutra base jurídica e, se não assentar, desistir desse tratamento.
Quando está em causa uma criança
Relativamente aos estudantes em idade de escolaridade obrigatória, o quadro é ainda mais delicado. Aqui, a capacidade para consentir, o papel dos pais ou encarregados de educação e o superior interesse da criança são questões que devem ser avaliadas separadamente.
Ao conceber uma plataforma educativa, é preciso estabelecer fluxos diferentes consoante a idade do utilizador. Oferecer a mesma interface tanto a um estudante de dez anos como a um estudante de mestrado de vinte e cinco é problemático não só em termos de usabilidade, mas também juridicamente. Um campo no modelo de dados que registe o grupo etário, com regras de tratamento diferentes associadas a esse campo, é a tradução técnica dessa distinção.
O que demonstra o registo de aprendizagem
O lado menos falado da tecnologia educativa é para que serve depois o registo que produz.
Quando um estudante contesta uma nota, o que tem a instituição em mãos? Um simples registo de "exame concluído", como quem fecha um bilhete, ou uma cadeia que mostre que resposta foi dada a cada pergunta, com que critério foi pontuada e quem a avaliou?
Se existir isto último, a reclamação resolve-se em dez minutos. Se não existir, a reclamação transforma-se numa defesa que pede que se confie no próprio registo da instituição, e essa defesa é fraca. Por isso, ao conceber um sistema de avaliação deve seguir-se esta ordem. Primeiro escreve-se o resultado de aprendizagem. Depois o critério de aprovação é ligado a esse resultado. A pergunta é gerada de acordo com o critério. O registo da avaliação é mantido. A via de reclamação e o procedimento de revisão são definidos antecipadamente.
Quando esta cadeia está construída, o certificado de aprovação tem por trás um fundamento demonstrável. Quando não está, o certificado fica reduzido a uma declaração que depende da boa-fé da instituição.
A minha recomendação às instituições
Antes de comprar software de vigilância, meçam que parte do problema de integridade pode ser resolvida pelo próprio desenho do exame. Na maioria das instituições essa medição nunca é feita, e passa-se diretamente para a solução mais intrusiva.
Se, depois dessa medição, a vigilância continuar a ser necessária, redijam uma justificação separada para cada dado recolhido. "O sistema recolhe isto" não é uma justificação. O dado cuja justificação não possa ser escrita deve ser retirado do sistema. Isto deve ser também objeto do contrato com o fornecedor, porque a maioria dos produtos prontos a usar recolhe mais do que é necessário e vem com essas definições por defeito.

## Porque é que um produto de software não está sujeito a uma só lei

Fonte: https://kulular.com.tr/pt/publicacoes/direito-digital

Como equipa que desenvolve software, encontramos esta pergunta sobretudo no início dos projetos. A organização pergunta que regras o software tem de cumprir, e a resposta não está numa só lei. Ter esta dispersão em conta na fase de conceção é muito mais barato do que remendar depois.
A pergunta "o que diz o direito digital sobre isto" não tem resposta, porque não existe um único texto chamado direito digital. Isto é a primeira coisa que qualquer pessoa que trabalhe nesta área aprende, e a mais difícil de explicar a um cliente.
Na Turquia, as atividades digitais são reguladas na interseção de pelo menos seis leis distintas. Nenhuma delas abrange as outras. Todas funcionam segundo a sua própria lógica, o seu próprio regime sancionatório e a sua própria autoridade de controlo. O resultado é o seguinte. Não é possível elaborar uma lista de obrigações a partir de um único texto, e o mesmo facto pode produzir consequências simultâneas ao abrigo de mais do que um regime ao mesmo tempo.
Uma violação de dados aparece em três lugares distintos
Convém ver isto com um exemplo concreto. Suponha-se que se obteve acesso não autorizado à base de dados de clientes de uma empresa de comércio eletrónico e os dados foram extraídos.
A primeira via é administrativa. O artigo 12.º da Lei 6698 regula as obrigações de segurança dos dados, e o parágrafo quinto desse mesmo artigo exige que a violação seja notificada ao Conselho. O Conselho avalia a suficiência das medidas técnicas e administrativas adotadas e, se as considerar insuficientes, aplica uma coima administrativa.
A segunda via é criminal. O facto praticado por quem obteve o acesso pode constituir o crime de acesso a um sistema informático nos termos do artigo 243.º da Lei n.º 5237, e a extração dos dados pode constituir o crime de transmissão ou obtenção ilícita de dados nos termos do artigo 136.º. Esta investigação decorre independentemente da responsabilidade administrativa da empresa.
A terceira via é de direito privado. A pessoa cujos dados foram divulgados pode pedir a reparação do dano sofrido. A última alínea do artigo 11.º da Lei reserva expressamente este direito.
As três vias não são alternativas entre si, funcionam ao mesmo tempo. Ter pago a coima do Conselho não põe fim à investigação criminal, e o resultado do processo penal não resolve por si só o pedido de indemnização.
A que pergunta responde cada lei
A forma mais prática de compreender a dispersão desta área é ver a que pergunta cada texto responde.
A Lei 6698 responde à pergunta "pode tratar este dado?". Aqui estão as condições de tratamento, o dever de informar, as medidas de segurança e os direitos do titular dos dados.
A Lei n.º 5651 responde à pergunta "quem é responsável por este conteúdo?". Esta lei regula a distinção entre fornecedor de conteúdo, fornecedor de alojamento, fornecedor de acesso e fornecedor de uso coletivo, bem como os procedimentos de remoção de conteúdo e de bloqueio do acesso. O regime de responsabilidade muda por completo consoante qual destas quatro qualidades a pessoa tenha.
A Lei n.º 5237 responde à pergunta "este facto é crime?".
A Lei n.º 6563 responde à pergunta "pode enviar esta comunicação comercial e o que é obrigado a declarar como prestador de serviços?".
A Lei n.º 5070 responde à pergunta "esta assinatura eletrónica substitui a assinatura manuscrita?".
Num projeto, normalmente todas estas perguntas surgem ao mesmo tempo. Uma decisão tomada olhando apenas para uma delas cria cegueira em relação às outras quatro.
Competência dispersa significa controlo disperso
O que torna este quadro ainda mais complicado é o facto de leis diferentes estarem confiadas a organismos diferentes.
A Autoridade de Proteção de Dados Pessoais fiscaliza as atividades de tratamento de dados. O organismo turco de tecnologias da informação e comunicação é competente na área das comunicações eletrónicas e participa na execução das decisões de bloqueio de acesso. O Ministério do Comércio é responsável pela aplicação da legislação de comércio eletrónico.
A consequência prática disto é a seguinte. Num único produto, pode ser responsável perante mais do que uma autoridade de controlo, e essas autoridades não estão vinculadas pela decisão umas das outras. Um parecer favorável de uma delas não impede que a outra chegue a uma conclusão diferente.
Onde se erra na prática
A grande maioria dos erros que vejo nesta área partilha uma característica comum. A avaliação jurídica é feita depois de as decisões técnicas já terem sido tomadas.
O modelo de dados já está construído, as tabelas já estão criadas, as integrações já estão escritas. Quando o produto está prestes a entrar em produção, diz-se ao advogado "pode dar uma vista de olhos, por favor". Nessa fase, o que pode ser dito é limitado, porque tudo o que se diz já implica uma correção retroativa, e essa correção retroativa cria um problema à parte quanto aos dados recolhidos até então.
No entanto, todas as perguntas seguintes são perguntas que poderiam ter sido respondidas ao construir o modelo de dados. Que categorias de dados pessoais serão tratadas. Em que base jurídica assentará cada categoria. Qual será o prazo de conservação e que componente o aplicará. A que tabelas se terá de aceder quando chegar um pedido de apagamento. Haverá transferência internacional de dados.
Cinco perguntas. Todas podem ter resposta numa única reunião. O custo que surge quando não têm resposta é muitas vezes superior ao custo dessa reunião.
A verdadeira dificuldade da área
A dificuldade do direito digital não está na complexidade das regras. As regras, lidas uma a uma, são compreensíveis.
A dificuldade está em saber em que momento cada regra entra em jogo. A decisão de um engenheiro de "guardemos também este campo, pode vir a ser preciso" produz consequências ao abrigo de três leis distintas, e quem toma essa decisão na maior parte das vezes não o sabe. A forma de colmatar esta lacuna de conhecimento não é preparar um dossiê de conformidade mais volumoso, é ter o jurista presente na mesa onde a decisão é tomada.