Skip to main content

Há um preconceito histórico de que o jurídico emperra a inovação. Soma-se a ele a falsa premissa de que ao jurídico caberá apenas inclusão ou revisão de cláusulas contratuais, como se fosse pouca coisa. Em tecnologia, esse viés é ainda mais danoso, tanto porque as alterações de cláusulas ou mesmo a revisão delas dependem de várias outras informações e análises, sobretudo quando há tratamento de dados pessoais, como pelo fato de que algumas delas poderão implicar a revisão de todo o projeto, quando não a sua interrupção por impossibilidade jurídica.

Inovação e segurança jurídica não disputam espaço: sustentam-se uma à outra ou desabam juntas.

A segurança jurídica evita que a empresa fique exposta a uma sanção, a um litígio ou à nulidade de um contrato decorrente, por exemplo, de um tratamento de dados para o qual sequer existe hipótese legal permissiva, ou que fira princípios como os da necessidade (minimização), adequação e finalidade. Para a prática em proteção de dados, os princípios orientam a rotina diária e legitimam o tratamento de dados como um guia prático, não mera bússola axiológica.

O jurídico, portanto, deve compreender questões técnicas para acomodar o produto tecnológico à regra jurídica adequada, quando possível, ou indicar desde o início as mudanças que o time de desenvolvimento deverá implementar. As cláusulas contratuais somente serão efetivas quando, após desenhada a solução e testada diante da LGPD, refletirem a realidade do fluxo de tratamento realizado pela aplicação.

Para chegar a esse ponto, porém, é preciso inverter a posição do jurídico. Em vez do revisor que aparece no fim para dizer “não”, ele deve participar desde a ideação, estar ao lado de quem programa e de quem decide o negócio. Somente assim é possível buscar a máxima segurança jurídica, seja em contratos com fornecedores, seja em operações societárias envolvendo ativos de tecnologia, seja em atividades com ou sem dados pessoais.

Participar desde a ideação, contudo, exige um advogado que entenda a tecnologia — não para virar engenheiro de software, mas para conseguir participar da discussão enquanto ela ainda pode ser moldada. Quem lê um fluxo de dados, entende uma chamada de API e sabe o que um agente de IA faz sozinho (e o que ele não controla) enxerga o risco antes de ele se tornar dano. E são decisões concretas, nada abstratas: até onde uma automação pode ir sem um humano no circuito? Quais atividades de tratamento de dados pessoais ela realiza e quais realmente precisa tocar? Que rastro vai permitir explicar, daqui a dois anos, por que o sistema decidiu o que decidiu? São perguntas jurídicas e, ao mesmo tempo, de arquitetura de produto.

Nada disso é trabalho solo do jurídico. Os projetos que dão certo têm uma coisa em comum: jurídico, tecnologia e negócio conversam desde o início, e cada um enxerga um risco que os outros não veem. O advogado sozinho não constrói o produto; o time técnico sozinho não mede o risco regulatório; o negócio sozinho não percebe onde a pressa vai cobrar a conta lá na frente. É dessa costura que nasce uma boa solução — e foi ela que me trouxe para a sociedade da Lara Martins: um lugar com estrutura para trabalhar exatamente assim.

É essa a prática que trago. Não a de quem promete inovação sem risco, porque isso não existe, mas a de quem trata o risco como parte do projeto. Nos próximos anos, a vantagem não vai ser de quem apenas adota IA; vai ser de quem consegue colocá-la para rodar com governança suficiente para continuar de pé quando os problemas surgirem. Rapidez e segurança nunca foram antagônicas; só precisam caminhar juntas desde o início.