El text alternatiu a les imatges és un d'aquells aspectes que tothom sap que importa, però que rarament rep l'atenció que mereix. Per a llocs amb centenars o milers d'imatges, escriure descripcions manualment resulta repetitiu i fàcil de posposar. Aquesta necessitat va portar a crear un generador de text alternatiu amb intel·ligència artificial per a WordPress, un projecte que combina visió artificial, un backend escalable i una integració neta amb l'ecosistema de plugins. No obstant això, el veritable valor no està només a generar alt text, sinó a fer-ho de manera fiable, segura i mesurable. Durant el desenvolupament van sorgir lliçons que van molt més enllà de la IA: la telemetria ben dissenyada, la prevenció de duplicats en events, el seguiment d'accions a través de múltiples sistemes i la privacitat per defecte. Aquí compartim aquests ensenyaments, des de la perspectiva de Q2BSTUDIO, empresa especialitzada en aplicacions a mida i solucions tecnològiques avançades.
El plugin es recolza en una arquitectura que va més enllà del típic script de WordPress. D'una banda, el panell d'administració en PHP gestiona la biblioteca de mitjans, mentre que un backend en Node.js allotjat a Render processa les sol·licituds de generació. Les dades de subscripcions i ús resideixen a Supabase, els pagaments es gestionen amb Stripe i l'analítica es recull amb PostHog. El flux comença quan l'usuari sol·licita generar alt text per a una o diverses imatges; el plugin envia una petició autenticada al backend, que valida la quota disponible, envia la imatge a un servei de visió per IA, desa el resultat i retorna la descripció. Tot això sembla senzill, però cada pas va introduir desafiaments que van obligar a repensar el disseny.
El primer gran repte va ser la telemetria. En un moment donat, les mètriques mostraven '4 inicis de generació' i '13 finalitzacions', cosa que semblava un error de duplicats. La causa real era que 'inici' mesurava treballs (jobs) i 'finalització' mesurava imatges individuals dins d'un treball per lots. Comparar ambdues mètriques directament era com comparar viatges al supermercat amb productes comprats. La solució va ser definir events semàntics clars: generation_job_started, generation_item_completed, generation_job_completed i generation_job_failed. Cada treball rep un generation_run_id únic, i cada imatge un generation_item_id. Això permet respondre preguntes concretes: quants treballs van començar, quantes imatges es van processar, quants treballs van finalitzar amb èxit i quants ítems van fallar dins d'un lot. La lliçó és que la semàntica dels events importa tant com recollir-los.
El segon desafiament va ser evitar duplicats a la telemetria. Els events poden disparar-se múltiples vegades per clics repetits, rerenderitzats, reintents o emissions des de frontend i backend simultàniament. Per fer-ho tolerant a reintents, es van afegir identificadors estables de PostHog ($insert_id) i es va definir quin sistema és propietari de cada event: el frontend registra la intenció de l'usuari (com fer clic a un botó d'actualitzar), el backend registra la creació exitosa d'un Checkout Session, els webhooks de Stripe determinen la finalització del pagament i l'activació de la subscripció, i el backend registra l'alt text només després d'haver-lo persistit. Això evita que una mateixa acció es compti dues o tres vegades per diferents parts de l'aplicació.
El tercer repte va ser seguir una acció a través de diversos sistemes. Un procés de pagament pot passar per WordPress, el backend, Stripe, el seu webhook, Supabase i PostHog. Sense un identificador compartit, depurar aquest viatge és tediós. Es van introduir correlation_id, checkout_attempt_id, generation_run_id, signup_attempt_id, session_id i site_install_id. Aquests identificadors permeten seguir una mateixa acció des del plugin fins als serveis externs. Quan un checkout s'abandona o un inici de sessió falla, el mateix correlation_id apareix a tots els sistemes, en lloc d'haver de buscar per marques de temps desconnectades.
El quart repte va ser la telemetria segura d'autenticació. Un event genèric de 'login_failed' no és útil perquè no indica si la causa va ser credencials incorrectes, compte deshabilitat, limitació de taxa, timeout de xarxa, API no disponible, fallada en creació de token o fallada en emmagatzematge de sessió. Es va implementar una taxonomia interna d'errors controlada, amb missatges públics genèrics per no revelar si un compte existeix. Es registren codis interns com invalid_credentials, account_disabled, rate_limited, network_timeout, api_unavailable, token_creation_failed, session_creation_failed i unknown_auth_error. Contrasenyes, tokens i respostes crues s'eliminen abans d'enviar la telemetria.
El cinquè repte va ser la privacitat per defecte. L'analítica de producte pot convertir-se ràpidament en un problema de privacitat si no es cuida. La capa de telemetria elimina camps com adreces de correu, llicències, tokens, claus API, contingut d'alt text, noms de fitxer, URLs, prompts i respostes completes de l'API. La gravació de sessions de PostHog està desactivada per defecte. L'analítica ha de descriure què va passar sense copiar el contingut amb què l'usuari estava treballant.
Si haguéssim de començar de nou, definiríem el contracte d'analítica abans de construir els panells, documentant cada event amb el seu desencadenador exacte, si és propietat del frontend o backend, si es dispara una vegada per usuari, sessió, treball, ítem o transacció, les propietats requerides, l'estratègia de desduplicació i la versió de l'esquema. Retocar la telemetria a posteriori és possible, però molt més treball que dissenyar-la bé des del principi. També afegiríem correlation IDs des del dia u: són barats d'implementar i enormement valuosos quan l'aplicació abasta múltiples serveis.
La lliçó més gran és que construir la funcionalitat de generació amb IA va ser només una part del producte. Un plugin llest per a producció necessita també autenticació fiable, gestió de subscripcions i quotes, webhooks idempotents, analítica respectuosa amb la privacitat, semàntica d'events clara, classificació d'errors, observabilitat d'extrem a extrem i un pla de migració per a telemetria antiga. La IA pot ser la característica estrella, però la fiabilitat és el que la converteix en un producte utilitzable.
A Q2BSTUDIO sabem que darrere de qualsevol solució aparentment simple hi ha una complexitat d'integració, seguretat i anàlisi que marca la diferència. Per això oferim serveis d'intel·ligència artificial a mida, així com consultoria en ciberseguretat, cloud AWS/Azure, BI amb Power BI i agents d'IA. Cada projecte ens ensenya que l'excel·lència tècnica no està només en l'algorisme, sinó en l'orquestració de sistemes, la telemetria ben dissenyada i l'experiència d'usuari final. Aquest generador d'alt text n'és un exemple: el més valuós no és la generació en si, sinó tot el que l'envolta perquè funcioni de manera robusta i fiable.
