Programação por descrição e segurança: o que os líderes precisam de saber sobre as equipas que desenvolvem com IA
Disparidade de conhecimentos sobre IA: Os líderes enfrentam desafios à medida que os membros das equipas os ultrapassam no domínio das ferramentas e capacidades de IA.
Programação por descrição explicada: Os trabalhadores não técnicos criam ferramentas funcionais através de instruções, colmatando as lacunas entre as ideias e a sua execução.
Preocupações de segurança: As ferramentas de programação por descrição não geridas colocam riscos relacionados com o tratamento e a exposição de dados, especialmente no que diz respeito às vulnerabilidades dos dados pessoais identificáveis.
Implicações de custos: A utilização não otimizada de ferramentas de IA pode resultar em despesas inesperadas e riscos financeiros.
Problemas de escalabilidade: As ferramentas criadas com programação por descrição que sejam bem-sucedidas necessitam de supervisão profissional para garantir a escalabilidade e a fiabilidade.
Sejamos honestos: estamos todos em pontos diferentes no que diz respeito à IA. E, para os líderes, isto pode ser inquietante — mais do que nunca, os seus subordinados diretos estão a ultrapassar os seus gestores em conhecimento e capacitação em IA, avançando rapidamente e, muitas vezes, estragando coisas.
Embora muitas organizações estejam a incentivar a exploração aberta de ferramentas de IA, a programação por instruções — a próxima fase da capacitação em IA para muitos colaboradores não técnicos — é uma aventura que envolve diferentes graus de risco, dependendo do que está a construir, para quem o está a construir e que dados estão a ser armazenados e utilizados.
Isto está a tornar-se especialmente frequente nas equipas de gestão de projetos e operações, onde criar ferramentas proprietárias é muitas vezes a resposta óbvia às necessidades dos processos — e, com os agentes de programação de IA, nunca foi tão fácil dar luz verde.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Para nos ajudar a compreender o que devemos ter em atenção quando as equipas começam a criar, convidei Tim Fisher, VP de IA do DPM, para nos explicar tudo. Este artigo destina-se a qualquer pessoa que tenha recebido uma mensagem do tipo "Olá, chefe, veja esta coisa fantástica que criei com o Claude!" — esperamos que seja útil.
Primeiro, o que é a programação por instruções? E porque é realmente valiosa?
Para efeitos deste artigo, programação por instruções significa programar através de comandos — especificamente, por alguém que não é técnico. Isto é diferente de um programador de software que utiliza uma ferramenta como o GitHub Copilot, em que a pessoa continua a contribuir com conhecimentos técnicos relevantes para o trabalho. Estamos a falar do diretor financeiro, do coordenador de operações ou do gestor de projetos que nunca escreveu uma linha de código e que agora lança ferramentas funcionais utilizando apenas comandos em linguagem natural.
E a perspetiva inicial de Fisher pode surpreendê-lo: ele está genuinamente entusiasmado com isto. "Adoro a ideia de pessoas que não sabem programar poderem agora ter uma forma de tirar da cabeça aquilo que querem e transformá-lo numa forma que todos possam ver, explorar e utilizar", afirma. "É uma forma de comunicar que não existia antes." Ele apresenta isto menos como uma capacidade técnica e mais como um novo meio de comunicação — um meio que reduz a distância entre a visão e a execução para pessoas que sempre tiveram ideias, mas não dispunham do vocabulário técnico necessário para as expressar.
A programação por instruções é uma forma de comunicar que não existia antes.
"É um pouco semelhante aos desafios que as pessoas enfrentam quando trabalham com equipas de design", explica Fisher. "Não consigo desenhar nem uma figura de pau. Por isso, quando quero comunicar algo visual a alguém, fico muito contente por existirem agora ferramentas que me permitem explicar algo através de muitas palavras bem pensadas, algo em que sou bom, e obter, no outro extremo, algo que outra pessoa que sabe desenhar olha e diz: 'Ah, agora sei o que pretende.'"
Para os líderes, esta mudança de perspetiva é importante. O impulso de encerrar tudo por completo ignora aquilo que é genuinamente útil: a programação por instruções pode acelerar o alinhamento, revelar ideias mais rapidamente e dar aos membros não técnicos da equipa uma nova forma de contribuir. A questão não é saber se deve permiti-la. É saber se compreende o que acontece depois de a ferramenta ser criada.
Onde termina o valor — e começa o risco
Fisher tem o cuidado de separar a fase de "comunicação" da programação por instruções daquilo que tende a acontecer depois — e é aí que o seu tom muda. "Penso que, na maior parte das vezes, o valor provavelmente termina aí", afirma. "É uma forma muito melhor de comunicar ideias e orientações. Mas o que descobrimos é que podem acontecer certas coisas depois disso que vão além de 'Vejam, comuniquei-vos uma ideia e agora partilhamos uma linguagem'. E é aí que se torna assustador."
O problema não está nos comandos. Está na implementação. Está no momento em que um protótipo se transforma numa ferramenta que pessoas reais utilizam, que armazena dados reais, que funciona em segundo plano numa infraestrutura real — e a pessoa que a criou continua sem saber o que está a acontecer nos bastidores.
As vulnerabilidades de segurança que os líderes devem conhecer
PII e tratamento de dados
O risco mais intuitivo para a maioria dos líderes estará relacionado com informações de identificação pessoal (PII). Fisher utiliza um exemplo concreto para ilustrar onde se situa o limite: "Penso que o limite da complexidade estaria mesmo antes da introdução de dados de colaboradores ou clientes num sistema que devolve esses dados a outras pessoas. É nessa altura que surgem problemas relacionados com PII."
Penso que o limite superior da complexidade estaria mesmo antes da introdução de dados de funcionários ou clientes num sistema que regurgita esses dados para outras pessoas.
O risco aumenta proporcionalmente à sensibilidade dos dados e ao público que lhes pode aceder — e, nas equipas de operações e gestão de projetos, esses dados incluem frequentemente informações de clientes, registos de funcionários, dados de remuneração ou dados de contacto que acarretam uma exposição jurídica real.
Custos Descontrolados e Utilização de Tokens
Um risco que apanha muitos líderes desprevenidos não tem nada que ver com dados e tem tudo que ver com dinheiro. Fisher descreve um cenário mais comum do que a maioria das pessoas imagina: "Suponhamos que alguém, acidentalmente, orienta um programador baseado em agentes na direção errada, fazendo com que este crie um ciclo que funciona continuamente, acumulando constantemente uma tarifa elevada. E, antes de dar por isso, um projeto que deveria custar $5,000 custa $50,000, porque essa pessoa não sabia o que estava a acontecer nos bastidores e presumiu que o programador baseado em agentes detetaria o problema."
As pessoas que criam soluções sem conhecimentos técnicos também têm menos probabilidades de otimizar, em geral, a utilização de tokens, o que significa que os custos podem acumular-se silenciosa e rapidamente. Sem visibilidade sobre a infraestrutura em que as suas ferramentas estão a funcionar, os membros da sua equipa poderão não perceber que existe um problema até receberem a fatura.
Chaves de API e Segurança da Informação
É aqui que Fisher entra no território que mantém as equipas de segurança acordadas durante a noite. O cenário que descreve é um exemplo clássico do que corre mal quando alguém sabe o suficiente para ser perigoso: "Um erro comum ocorre quando alguém sabe o suficiente para perceber e explicar que precisa de uma chave de API para fazer algo acontecer. Essa pessoa fornece a chave num pedido, e ela não é armazenada num local secreto — é simplesmente despejada num ficheiro ou escrita diretamente no script. Depois, alguém publica o código no GitHub, talvez se esqueça de o tornar privado, e agora essa chave de API pode ser utilizada de forma abusiva por qualquer pessoa disposta a fazer algo ilícito, como acumular uma fatura de tokens de $100K.”
É fácil ler esse cenário e pensar que exige uma longa cadeia de erros. Fisher contesta esse instinto: "Parece que existe uma longa sequência de acontecimentos improváveis, mas não é nada improvável. Na verdade, é extraordinariamente comum, sobretudo entre pessoas sem conhecimentos técnicos.”
Talvez o risco mais alarmante apontado por Fisher seja um em que até programadores experientes já caíram. "Ouvi histórias aterradoras sobre programadores experientes que introduziram toda a base de código de uma empresa num programador baseado em agentes e ajustaram alguma coisa, acabando por expor toda a base de código a outra empresa, inteiramente dentro dos limites da lei." Se programadores experientes podem cometer este erro, o perfil de risco de um funcionário sem conhecimentos técnicos que cria rapidamente e sem supervisão é consideravelmente mais elevado.
More Articles
- A ascensão da programação por linguagem natural: poderá ser útil para gestores de projetos?
- O Gestor Principal de Engenharia afirma que os responsáveis pela entrega devem adotar sistemas em tempo real orientados por sinais
- Líder de entrega na Google partilha como os fluxos de trabalho baseados em agentes estão a transformar os modelos de gestão de produto
- Este antigo gestor de produto da Google está a mudar a forma como as equipas de projeto trabalham com uma ferramenta de gestão de produto baseada em agentes de IA
- Como uma gestora de projetos experiente utiliza a IA para acelerar a entrega
O Problema da Escalabilidade — O Que Acontece Quando Funciona Realmente
Uma das conversas mais difíceis para os líderes é decidir o que fazer quando uma ferramenta criada através de vibecoding resolve genuinamente um problema e as pessoas começam a depender dela. O caso de sucesso pode transformar-se silenciosamente numa responsabilidade. Fisher é claro quanto ao problema estrutural: "De um modo geral, todos os projetos criados através de vibecoding não são escaláveis, sobretudo porque não se pede ao agente que tenha em consideração a escalabilidade. É provável que os não programadores nem sequer peçam funcionalidades como o tratamento de erros. Se não compreender os contextos em que os erros ocorrem, não sabe o suficiente para garantir que o agente os deteta e lida com eles de forma adequada."
De um modo geral, todos os projetos criados através de codificação assistida por IA não são escaláveis, sobretudo porque não está a pedir ao agente que tenha em consideração a escalabilidade.
A lacuna de responsabilização torna-se mais visível quando há pressão. «O que tende a acontecer é alguém criar algo através de codificação assistida por IA e, depois, isso funcionar, mas será que essa pessoa vai prestar suporte técnico 24 horas por dia, 7 dias por semana, para este produto?» Para os líderes de entrega e operações, este é o momento em que uma ferramenta interna bem-intencionada se transforma num risco organizacional — porque, quanto mais as equipas dependerem dela, maior será a probabilidade de avariar ou de precisar constantemente de suporte técnico.
A recomendação de Fisher para as ferramentas que ganham adesão é uma transferência clara: «Se criar algo de que as pessoas dependam, isso tem de se tornar mais do que um simples projeto criado através de codificação assistida por IA; tem de ser integrado pelas pessoas que fazem isto profissionalmente e que sabem coisas que nem sequer sabe que deve perguntar.»
O que os líderes podem fazer — medidas práticas de proteção
Nada disto significa que a resposta seja uma proibição generalizada. Fisher é consistente neste ponto — o valor da codificação assistida por IA para pessoas não técnicas é real, mas aplica-se a uma área específica. «O valor destas ferramentas para quem não programa é poder simplificar coisas como o alinhamento em torno de uma ideia e ultrapassar a fase do “isto vai funcionar?”,» afirma. A fase do protótipo, a fase da comunicação, a fase do «será que vale sequer a pena criar isto?» — é aí que a codificação assistida por IA se destaca e onde o risco continua a ser controlável.
Para os líderes, o guia prático será algo semelhante a isto: incentivar a codificação assistida por IA como ferramenta de prototipagem e comunicação e estabelecer um limiar claro a partir do qual uma ferramenta deve ser analisada por alguém com conhecimentos técnicos antes de ser utilizada de forma mais abrangente. Ter estas conversas com a sua equipa — para que compreenda os riscos e conheça as suas opções — é o que distingue uma cultura de exploração inteligente da IA de outra que se limita a avançar rapidamente e a esperar pelo melhor.
O objetivo não é ser o líder que diz que não. É ser o líder que garante que a equipa sabe no que se está a envolver — para que, quando alguém criar algo excelente, isso possa realmente avançar.
Quer mais informações como estas? Crie uma conta DPM gratuita para ouvir mais especialistas como estes.
