Quan parlem d’intel·ligència artificial, és fàcil pensar que construir una eina pròpia implica entrenar un model.
En molts casos, no és així.
Una part important dels sistemes útils que s’estan construint avui no parteixen d’un model desenvolupat des de zero, sinó d’una arquitectura que combina fonts d’informació, programació, automatització, regles, dades estructurades i, només quan aporta valor, models d’IA generalistes.
La potència no està únicament en el model. Està en el sistema.
Arquitectura bàsica
fonts → captura → normalització → regles → scoring → IA → visualització → decisió
De la conversa al sistema
Un model pot resumir una oferta de feina, analitzar una descripció o classificar un text.
Però un sistema comença a ser realment útil quan aquesta capacitat s’integra dins d’un flux més ampli. El domini pot canviar —mercat laboral, música, recerca científica, borsa, esports o immobiliària— però l’arquitectura sovint comparteix els mateixos principis.
Primer: obtenir les dades
La primera capa no és necessàriament IA. És adquisició de dades.
Aquestes dades poden arribar mitjançant APIs, feeds, bases de dades obertes o directament des del web.
Quan no existeix una API adequada, una opció és utilitzar un scraper: un programa capaç de visitar una pàgina web, identificar determinats elements i transformar-los en dades estructurades.
event = {
"venue": "Example Club",
"date": "2026-10-30",
"artists": ["Artist A", "Artist B"],
"city": "Amsterdam"
}En aquest punt, ja no treballem només amb una pàgina web.
Estem treballant amb dades.
Python com a capa d’orquestració
En molts d’aquests sistemes, Python actua com a llenguatge d’unió entre components. No és “la IA”, sinó la capa que permet connectar processos i dades.
- fer peticions HTTP
- processar HTML
- consumir APIs
- netejar i normalitzar dades
- comparar registres
- aplicar regles
- calcular puntuacions
- detectar coincidències
- emmagatzemar resultats
- alimentar dashboards
Biblioteques com requests, BeautifulSoup o pandas, juntament amb eines de visualització com Streamlit, permeten construir prototips funcionals amb una infraestructura relativament petita.
El model pot ser opcional; l’arquitectura no.
De l’arquitectura als casos reals
La utilitat d’aquest enfocament es veu millor quan l’apliquem a problemes concrets. Una mateixa arquitectura pot adaptar-se a dominis molt diferents si canviem les fonts, els criteris i la manera de representar la informació.
A DeGalaLab estem experimentant amb aquesta idea en projectes aplicats a contextos diversos: des d’un sistema d’intel·ligència musical fins a un radar de seguiment d’oportunitats professionals.
Els objectius són diferents, però la lògica és semblant: recollir informació dispersa, estructurar-la, aplicar criteris i convertir-la en senyals útils per prendre decisions.
MIA: intel·ligència aplicada a un ecosistema musical
MIA —Music Intelligence Agent— parteix d’un problema molt concret: la informació rellevant per a un projecte musical està dispersa entre clubs, programacions, artistes, promotors, plataformes i agències.
El repte no és que la informació no existeixi. El repte és trobar-la, estructurar-la i relacionar-la.
venues → scrapers → events → normalització → scoring → oportunitats
Els connectors recullen esdeveniments de diferents fonts. Python transforma estructures diferents en un model comú. Després s’apliquen criteris i puntuacions per reduir centenars d’esdeveniments a un conjunt molt més petit de senyals que mereixen atenció.
No hi ha cap model entrenat específicament per “entendre” el projecte musical.
Hi ha un sistema construït per representar criteris, observar fonts i detectar senyals.
Un radar professional en evolució
El segon projecte parteix d’un problema diferent: com seguir oportunitats professionals, detectar patrons i comparar ofertes sense dependre només de cerques puntuals o portals de feina.
De moment, el sistema funciona sobre una base relativament simple però útil: un full de càlcul automatitzat que centralitza ofertes, competències, eines, sectors, criteris d’encaix i puntuacions.
Aquesta primera versió permet estructurar la informació i construir una lògica de comparació abans d’afegir més automatització.
El següent pas serà evolucionar-lo cap a un sistema capaç de recopilar oportunitats de manera automàtica mitjançant scrapers i altres fonts de dades, normalitzar-les i aplicar criteris de classificació i scoring de manera continuada.
El projecte està encara en evolució, però la direcció és clara: passar d’un radar assistit per dades a un agent d’intel·ligència especialitzat en oportunitats de Data Science.
ofertes → captura → normalització → competències → classificació → scoring → revisió
Un radar de feina: una arquitectura similar, un domini diferent
El Radar de Feines funciona sobre un problema completament diferent, però comparteix una lògica semblant.
Una oferta pot contenir perfil professional, competències, eines, ubicació, jornada, sector, experiència requerida o modalitat de treball.
ofertes → extracció → competències → classificació → scoring → revisió
Aquesta estructura permet detectar coses que una cerca convencional pot passar per alt: una oferta pot no dir “Data Steward” al títol però requerir metadata, data governance i FAIR Data; una altra pot tenir un encaix tècnic molt alt però una compatibilitat logística baixa.
El sistema no pren la decisió.
Construeix una capa d’intel·ligència abans de la decisió.
El mateix patró en altres camps
Recerca científica
papers → abstracts → keywords → citacions → classificació → alertes
Seguiment de publicacions, detecció de línies emergents i identificació de treballs rellevants.
Esports
partits → estadístiques → jugadors → mètriques → patrons
Borsa
mercats → dades → indicadors → esdeveniments → senyals → dashboard
Immobiliària
anuncis → preus → superfície → ubicació → característiques → scoring
El valor no prové necessàriament de “tenir una IA”. Prové de convertir un problema difús en una estructura observable.
I on entra la IA?
Un model d’IA pot ser especialment útil per classificar text poc estructurat, extraure conceptes, resumir informació, normalitzar llenguatge, detectar relacions semàntiques o generar explicacions dels resultats.
Però és important distingir el model del sistema.
- Un LLM pot interpretar una descripció.
- No necessàriament recull les dades.
- No necessàriament les guarda.
- No necessàriament executa el procés cada dia.
- No necessàriament calcula totes les puntuacions.
Regles, scoring i models híbrids
No tot ha de ser resolt per un model probabilístic. Una regla explícita pot ser perfecta per determinar que una oferta de 40 hores no compleix un criteri determinat. Un scoring numèric pot ajudar a ordenar oportunitats. Una expressió regular pot detectar un patró.
Un model d’IA pot interpretar una frase ambigua.
Aquest tipus d’arquitectura híbrida acostuma a ser més transparent, controlable i fàcil de depurar que delegar-ho tot a un únic model.
Ha fallat el scraper? La normalització? La regla? El scoring? La classificació? El model?
Aquesta traçabilitat és essencial quan una eina deixa de ser un experiment i comença a formar part d’un procés de treball.
No cal autonomia total
Parlar d’agents d’IA sovint porta a imaginar sistemes completament autònoms. Però l’autonomia no és necessàriament l’objectiu.
- buscar
- actualitzar
- comparar
- detectar canvis
- prioritzar
- avisar
I deixar la decisió final a una persona.
En molts contextos, el millor agent no és qui decideix per nosaltres. És qui ens permet veure millor.
Construir sistemes, no només prompts
Potser aquest és un dels canvis més interessants de l’actual etapa de la IA.
Durant un temps hem après a formular millors preguntes. Ara estem començant a aprendre una altra cosa: com construir arquitectures que treballin de manera continuada sobre problemes reals.
Amb dades. Amb codi. Amb automatització. Amb regles. Amb models quan cal. I amb criteri humà al centre.
No cal entrenar un model propi per començar.
De vegades, la part més intel·ligent no és el model. És la manera com connectem totes les peces.
