Aplicacions que negoci crea amb IA sense passar per enginyeria

En un client vaig veure com negoci construïa les seves pròpies aplicacions amb IA i com, després, hi apareixien problemes de govern i seguretat.

El que negoci construeix amb un agent és programari, encara que ningú no l'anomeni així, i es governa com el programari: amb controls dins de la plataforma on es construeix, una revisió que depèn de les dades que toca i un responsable que hi continua quan el seu autor canvia de lloc de feina. Muntar-ho li toca a enginyeria, i com més aviat, millor.

Quant es construeix ja fora d'enginyeria

Aquesta manera de treballar s'anomena vibe coding: descriure en llenguatge natural el que vols, deixar que un agent n'escrigui el codi i quedar-te amb el que funciona sense llegir-lo. Va començar entre desenvolupadors amb pressa i ara la fan servir persones que no han programat mai.

Retool, que ven una plataforma per crear eines internes, va preguntar a finals del 2025 a 817 persones que construeixen programari a les seves empreses. El 60 % havia construït alguna cosa fora de la supervisió de TI l'últim any, i un 25 % ho fa sovint. Només el 36 % s'identificava com a enginyer o desenvolupador; la resta venia d'operacions, producte, dades, màrqueting, finances i altres àrees. I el 51 % ja tenia en producció alguna cosa que fa servir el seu equip.

El percentatge exacte importa menys que la direcció: en moltes empreses, producte i operacions ja construeixen, amb permís o sense, i el que construeixen es queda en ús.

Hem acabat fent servir aquestes solucions de dues maneres: com a spikes, prototips que després enginyeria refactoritza, o proveint eines transversals que donen el harness (el context en què treballa la IA) a aquestes solucions.

Què canvia respecte del shadow AI de sempre

Al juliol vam escriure sobre el shadow AI: persones que fan servir eines d'IA sense que tecnologia ho sàpiga. El risc principal eren les dades que surten de l'empresa per una conversa. Amb el vibe coding apareix una altra cosa: una aplicació que s'executa, es connecta a dades de l'empresa i continua funcionant quan el seu autor ja és en un altre tema.

La Cloud Security Alliance ho descriu en una nota de juny del 2026. Una aplicació feta a base d'instruccions pot existir només com un servei desplegat, sense codi font que es pugui recuperar, sense inventari de dependències (les llibreries de tercers que fa servir) i sense registre de quin model ni quina instrucció la van generar. Quan apareix una fallada, l'arranjament passa per tornar a demanar-ho a la IA, perquè falta el codi propi que un equip pedaçaria.

Escape.tech, una empresa de seguretat, va analitzar el 2025 més de 5.600 aplicacions públiques fetes amb plataformes de vibe coding. Hi va trobar més de 2.000 vulnerabilitats, més de 400 secrets exposats (claus d'accés i credencials que haurien d'estar amagades) i 175 casos de dades personals a la vista. L'anàlisi va ser passiva, des de fora i sense trencar res, i els autors presenten les xifres com un mínim.

Les aplicacions ja existeixen. La pregunta útil per a un CTO és què hi posa el seu equip a sota perquè la següent neixi amb controls i la que ja funciona tingui un responsable.

Les quatre barreres, per aquest ordre

Lenny Zeltser, especialista en seguretat, escrivia al març del 2026 que les aprovacions prèvies fallen quan qui construeix no passa pels fluxos de treball d'enginyeria. La seva proposta i la de la nota de la CSA coincideixen en el bàsic: controls dins de les eines que la gent ja fa servir, i visibilitat per veure el que s'escapa. Ordenades pel que cal primer, queden així:

L'inventari, abans que qualsevol norma

Sense inventari, la resta de barreres arriba tard. Zeltser proposa que reculli quines dades fa servir cada eina, on s'executa, quins permisos té i qui n'és el responsable, i que el descobriment sigui automàtic: esperar que cada persona registri la seva aplicació deixa fora justament les que més preocupen. La CSA hi afegeix un registre lleuger i sense càstig, pensat per saber què hi ha abans de decidir res.

El primer inventari pot sortir de les plataformes que l'empresa ja té contractades: la nota suggereix començar pels seus panells de governança, que llisten aplicacions, autors i connexions a dades. El que no es veu des d'allà acostumen a ser les integracions que algú connecta pel seu compte, el mateix problema que donen els servidors MCP dins dels equips de desenvolupament.

La revisió, per nivells de dades

La segona barrera evita l'error més freqüent: revisar igual tot el que fa algú de fora d'enginyeria, que acaba en una cua llarga que la gent aprèn a saltar-se. La nota de la CSA proposa tres nivells. El que proposem per a cada un és un exemple per adaptar a cada empresa:

• Eines internes amb dades no sensibles: registre a l'inventari i comprovacions automàtiques, sense revisió manual.
• Aplicacions amb dades personals o regulades: a més, una revisió de seguretat abans d'obrir-les a més persones.
• Aplicacions que criden serveis d'IA o actuen soles, com un agent que envia correus o canvia registres: revisió d'enginyeria i permisos reduïts a l'imprescindible.

El nivell el marquen les dades i els permisos de l'aplicació. Un full de càlcul que algú de finances converteix en aplicació pot ser inofensiu o pot llegir les nòmines, i saber qui l'ha fet no ajuda a distingir-ho.

Les comprovacions, dins de la plataforma

Zeltser ho explica amb una frase pràctica: qui no és desenvolupador no llançarà eines de seguretat pel seu compte, així que aquestes eines han de funcionar sense ell. Per a un equip d'enginyeria és terreny conegut. L'escaneig de secrets, l'anàlisi de dependències i els permisos mínims ja viuen al seu pipeline, la cadena automàtica que comprova cada canvi abans d'integrar-lo. El que és nou és posar-los a la plataforma on construeix negoci i, on la plataforma no ho permet, demanar-ho al proveïdor per contracte, com recomana la CSA.

Un exemple del mercat: JPMorganChase ha obert Claude Code a equips que no són d'enginyeria, segons va publicar Anthropic el 9 de novembre del 2026. Ho fa en entorns controlats sobre la seva pròpia infraestructura, amb milers de proves automàtiques i portes d'aprovació que revisen cada canvi, i amb una regla explícita: «Claude can't sign off on its own work» (Claude no pot donar per bo el seu propi treball). Els models nous passen abans pel seu procés intern d'aprovació. És un banc amb recursos de banc, però l'ordre serveix per a qualsevol mida: primer l'entorn i les comprovacions, després l'accés a més gent.

Les aplicacions òrfenes

Zeltser també assenyala el problema que més triga a veure's: quan qui va fer l'aplicació canvia de lloc de feina o se'n va, l'aplicació es queda sense responsable. La seva proposta és senzilla. Registrar qui la va construir i quan es va actualitzar per última vegada, perquè algú l'heredi o la retiri.

Aquesta barrera és la que més s'oblida, perquè al principi totes les aplicacions tenen autor. El problema apareix al cap d'un any, amb la primera reorganització. Una aplicació que fa mesos que no canvia i que té l'autor en un altre equip és la primera candidata a revisar: continua llegint dades i ningú no la mira.

Què li toca a l'equip d'enginyeria

Jo penso que on cal anar és a construir un harness i un context corporatius i ajudar que negoci ho pugui fer bé. Estem davant del primer moment de la història en què alinear negoci i TI és molt senzill.

Si es mira la llista, les quatre barreres demanen una cosa que enginyeria ja sap fer: construir una plataforma amb regles escrites i comprovacions automàtiques, i mantenir-la. És el mateix que necessita quan el mateix equip treballa amb agents de codi, amb els permisos i el context ben posats. Canvia qui la fa servir.

Per això convé que el CTO no ho delegui com un afer de compliment normatiu d'una altra àrea. Qui construeix fora d'enginyeria necessita el mateix que un desenvolupador amb un agent: un context amb les regles de l'empresa i controls que aturin el que no ha d'entrar. Si enginyeria ho ofereix i és més ràpid que muntar-ho pel seu compte, la gent ho fa servir.

Amb els equips de desenvolupament treballem així: lliurem amb mètode i millorem amb dades, sobre el context que el teu equip construeix amb nosaltres: les seves regles, el seu coneixement del producte i controls automàtics.

Preguntes freqüents

Què és el vibe coding?

És construir programari descrivint en llenguatge natural el que es vol i deixant que un agent d'IA n'escrigui el codi, sovint sense llegir-lo. El fan servir desenvolupadors i, cada vegada més, persones de producte, operacions o finances que no han programat mai.

Quantes persones construeixen aplicacions fora de la supervisió de TI?

En una enquesta de Retool a 817 persones que construeixen programari a les seves empreses, feta a finals del 2025, el 60 % havia construït alguna cosa fora de la supervisió de TI l'últim any i un 25 % ho fa sovint. Retool ven una plataforma per crear eines internes.

Quins riscos tenen les aplicacions fetes amb vibe coding?

Escape.tech va analitzar més de 5.600 aplicacions públiques fetes amb aquestes plataformes i hi va trobar més de 2.000 vulnerabilitats, més de 400 secrets exposats i 175 casos de dades personals a la vista. La Cloud Security Alliance hi afegeix que moltes no tenen codi font recuperable ni registre del model que les va generar.

Com es governa el vibe coding en una empresa?

Amb quatre barreres, per aquest ordre: un inventari automàtic de quines aplicacions existeixen i qui n'és el responsable, una revisió per nivells segons les dades que toca cada aplicació, comprovacions automàtiques de secrets, dependències i permisos dins de la plataforma, i un pla per a les aplicacions que es queden sense responsable.

Què és una aplicació òrfena?

És una aplicació que continua en ús quan la persona que la va construir ha canviat de lloc de feina o se n'ha anat. Continua llegint dades i ningú la manté, així que algú l'ha d'heretar o retirar.

Quin paper té l'equip d'enginyeria?

Construir i mantenir la plataforma on construeix la resta de l'empresa: regles escrites, comprovacions automàtiques i permisos acotats. Són els mateixos elements que necessita quan el mateix equip treballa amb agents de codi.

Fonts

• Kelsey McKeon (Retool), «The build vs. buy shift: how vibe coding and shadow IT have reshaped enterprise software», 17 de febrer del 2026.
• Cloud Security Alliance (AI Safety Initiative), «The Vibe Coding Governance Gap», nota de recerca, 2 de juny del 2026.
• Nohé Hinniger-Foray, Gwendal Mognier i Alexandra Charikova (Escape.tech), «Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms», 29 d'octubre del 2025.
• Lenny Zeltser, «Security Governance at the Speed of Vibe Coding», 30 de març del 2026.
• Anthropic, «JPMorganChase expands Claude Code to more employees across the firm», 9 de novembre del 2026 (cas publicat pel fabricant).