Implementació d’IA
Com implantar IA en un centre de psicologia: pla responsable de 90 dies
Pla de 90 dies per adoptar IA en un centre de psicologia: inventari, riscos, selecció d’eines, pilot, mètriques, formació, governança i retirada.
Guia informativa amb criteris visibles, dades pràctiques i enllaços per ampliar la informació.
Adoptar intel·ligència artificial no hauria de significar obrir comptes en diverses plataformes i esperar que l’equip descobreixi com utilitzar-les. En un centre de psicologia, una implantació improvisada pot duplicar processos, exposar dades, crear notes incorrectes i generar una dependència difícil de revertir. Un pla curt, en canvi, pot provar valor sense posar la novetat per davant de la seguretat.
Aquest itinerari de 90 dies està pensat per a consultes i centres que volen explorar IA en administració, continguts, documentació o suport operatiu. No pressuposa que totes les eines siguin adequades ni que calgui arribar a producció. Descartar una tecnologia després d’un pilot és un resultat vàlid si no millora el servei o el risc és desproporcionat.
Abans del dia 1: defineix què no automatitzaràs
Una frontera explícita evita que el projecte creixi per inèrcia. Fins que no hi hagi una avaluació específica, convé deixar fora:
- diagnòstic automàtic;
- decisions de risc o priorització sense revisió humana;
- modificacions de tractament o medicació;
- enregistrament de sessions amb eines no aprovades;
- respostes autònomes davant crisi;
- càrrega d’expedients en models generals;
- avaluació de professionals o pacients mitjançant inferències opaques;
- decisions sobre menors o persones vulnerables basades només en la sortida d’un sistema.
La llista no afirma que tota tecnologia relacionada sigui sempre impossible. Estableix que aquests usos necessiten evidència, governança i validació molt superiors a les d’un pilot administratiu.
Dies 1–15: inventari i problema real
El primer objectiu és entendre la situació actual. Demana a cada rol quines eines utilitza, incloses extensions, transcriptors, comptes personals i funcions d’IA ja integrades en programes coneguts. L’inventari ha d’identificar propietari, finalitat, dades, cost, freqüència i dependències.
Després tria un problema mesurable. «Volem utilitzar IA» no és un problema. «Triguem dues hores setmanals a convertir notes internes no clíniques en una agenda de seguiment» sí que ho és. Altres exemples:
- massa temps per actualitzar preguntes freqüents públiques;
- informació d’horaris duplicada en diversos canals;
- dificultat per transformar reunions d’equip sense casos en llistes d’accions;
- revisió manual d’incoherències entre web i directori;
- retard a preparar materials de formació interna.
Per a cada problema, registra el temps actual, errors, persones implicades i conseqüència. Sense una línia de base, qualsevol demostració pot semblar eficient.
Dies 16–30: classifica risc i escriu requisits
La mateixa funció pot tenir un risc diferent segons les dades. Resumir un text públic no és resumir una sessió. Crear un calendari intern no és prioritzar persones segons el contingut del seu missatge.
Utilitza tres nivells inicials:
| Nivell | Exemple | Condició per provar |
|---|---|---|
| Baix | text públic, contingut fictici o tasca reversible | revisió humana i compte corporatiu |
| Mitjà | informació interna o decisió operativa amb impacte limitat | proveïdor revisat, permisos, registre i pilot tancat |
| Alt | dades de salut, menors, risc, avaluació o decisió clínica | avaluació formal, base jurídica, evidència, supervisió i validació especialitzada |
Els requisits han d’incloure funció i límits. Per exemple: «El sistema proposarà un esborrany a partir de contingut públic, no publicarà, no utilitzarà el text per entrenar, permetrà eliminar-lo i registrarà qui l’ha revisat». Aquesta frase és més útil que «volem el millor model».
Com comparar eines sense quedar-se en la demostració
Prepara una matriu amb el mateix pes per a tots els proveïdors:
| Criteri | Pregunta de compra | Prova requerida |
|---|---|---|
| Adequació | resol exactament la tasca prioritària? | demostració amb cas fictici propi |
| Precisió | quins errors comet i com es detecten? | conjunt de prova i revisió humana |
| Privacitat | utilitza dades per entrenar o millorar? | contracte i configuració verificable |
| Seguretat | com controla accessos i incidències? | documentació, permisos i registres |
| Transparència | es pot explicar el resultat i la intervenció de la IA? | mostra de sortides i historial |
| Integració | afegeix o elimina passos? | mapa del flux complet |
| Portabilitat | es poden exportar dades i configuració? | prova d’exportació |
| Cost total | inclou formació, revisió, integració i sortida? | estimació anual completa |
| Suport | qui respon davant una incidència crítica? | acord i canal documentats |
Una eina que genera un bon resultat en un minut pot continuar sent inadequada si obliga a revisar vint camps, no permet exportar o canvia condicions sense control.
Dies 31–45: dissenya el pilot
El pilot ha de tenir durada, participants, dades permeses, mètriques i criteris d’aturada. Comença amb contingut fictici o públic. No converteixis una prova en producció perquè la primera demostració ha anat bé.
Un document de pilot pot ocupar dues pàgines:
- Hipòtesi: què millorarà i per què.
- Abast: tasca, equip i volum.
- Exclusions: dades i decisions prohibides.
- Responsable: qui pot aturar la prova.
- Mètriques: temps, errors, qualitat, càrrega de revisió i satisfacció.
- Incidències: què es registra i com s’escala.
- Criteri d’èxit: llindar definit abans de veure el resultat.
- Criteri de retirada: error greu, falta de control o absència de valor.
Per evitar el biaix d’entusiasme, compara un conjunt de tasques amb el procés actual i amb la nova eina. Mesura també el temps de comprovar la sortida: un esborrany ràpid que necessita una revisió lenta pot no estalviar res.
Dies 46–60: formació i supervisió
La formació no s’ha de limitar a «com escriure prompts». L’equip ha d’entendre què no sap el sistema, quines dades no pot introduir, com detectar errors i quan escalar. També necessita exemples de respostes plausibles però falses.
Un taller útil inclou:
- diferència entre text fluid i informació validada;
- minimització i anonimització real;
- verificació de fonts i dates;
- errors de negació, atribució i context;
- llenguatge discriminatori o estigmatitzant;
- procediment d’aprovació;
- captura d’incidències sense dades innecessàries;
- dret de l’equip a aturar l’ús.
La supervisió es reparteix per rols. La persona que utilitza l’eina revisa la tasca; un responsable funcional avalua qualitat; privacitat o legal valida el tractament; direcció assumeix la decisió organitzativa. En usos clínics, la responsabilitat i el judici professional no es deleguen.
Dies 61–75: executa, mesura i busca els errors
Durant el pilot, no comptis només sortides correctes. Classifica errors:
- factuals: inventa una font, una dada o una funció;
- de context: barreja persones, dates o serveis;
- d’omissió: elimina una limitació important;
- de to: presenta una promesa o un missatge inadequat;
- de privacitat: reté o revela informació no prevista;
- operatius: falla la integració o duplica feina;
- d’equitat: funciona pitjor en un idioma, accent o perfil.
Per cada error, registra impacte, detecció i mesura correctora. Si només es detecta perquè una persona coneixia el cas, pregunta què hauria passat en un volum més alt o amb menys experiència.
Les mètriques finals han d’incloure:
| Dimensió | Indicador possible |
|---|---|
| Temps | minuts totals, inclosa la revisió |
| Qualitat | percentatge de sortides acceptades sense canvi material |
| Seguretat | incidències i quasi-incidències |
| Experiència | claredat i càrrega percebuda per l’equip |
| Continuïtat | facilitat d’exportar i tornar al procés anterior |
| Cost | llicència, integració, formació i supervisió |
Dies 76–90: decisió i governança
Al final, hi ha quatre opcions: adoptar, ampliar amb límits, repetir el pilot o descartar. La decisió ha d’explicar evidència i risc residual. «Ens agrada» o «tothom ho està fent» no són criteris suficients.
Si s’adopta, crea:
- propietari del sistema;
- inventari i versió aprovada;
- finalitats i dades permeses;
- grups d’accés;
- procediment de revisió;
- formació obligatòria;
- informació a les persones afectades;
- registre d’incidències;
- calendari de reavaluació;
- pla d’exportació i retirada.
La governança també ha de cobrir canvis del proveïdor. Una nova funció, un subencarregat o una política de conservació diferent poden alterar l’avaluació inicial. No s’ha de donar per aprovat automàticament tot allò que aparegui dins una eina ja contractada.
Criteris específics per a notes i documentació clínica
La documentació assistencial és un cas d’alt impacte. Abans d’avaluar un assistent de notes, el centre ha de definir quin problema resol, si necessita àudio complet i quina part continuarà redactant el professional.
La guia de l’APA per avaluar assistents de notes proposa revisar necessitats, privacitat, seguretat, precisió, biaix, integració, consentiment i responsabilitat. En la pràctica, cal comprovar errors especialment sensibles: negacions, risc, medicació, noms, cronologia i atribució de frases.
Cap nota s’hauria d’incorporar sense lectura i validació del professional. També s’ha de registrar que és un esborrany assistit quan això sigui rellevant per a la traçabilitat. La guia de protecció de dades i IA amplia el mapa de dades, contractes i conservació.
IA per a comunicació, SEO i continguts
Un centre pot començar per usos públics: ordenar preguntes reals, preparar esquemes o detectar duplicacions. Tot i així, publicar centenars de textos genèrics no és una estratègia. Google recomana contingut original, útil i centrat en les persones, amb autoria, exactitud i context sobre l’ús d’automatització quan sigui rellevant.
Una política editorial pot exigir:
- pregunta real de l’audiència;
- font principal verificable;
- aportació pròpia del centre;
- revisió professional identificada;
- data d’actualització;
- límits i següent pas prudent;
- enllaç a un servei o recurs que resolgui la necessitat.
El blog del directori combina guies assistencials i documentació per a professionals. La separació evita que una pàgina comercial es presenti com una recomanació clínica.
Quan convé suport extern
Un centre petit pot executar un pilot acotat amb recursos interns, però una integració amb diversos sistemes, dades sensibles o automatitzacions necessita especialitats complementàries. Karmina AI Studio pot ajudar a definir casos d’ús, arquitectura, proves i governança. L’equip de Karmina pot connectar la part web, continguts, analítica i captació amb el sistema digital del centre.
Aquest suport no substitueix la direcció clínica, l’assessorament jurídic, la protecció de dades ni la participació de les persones afectades. Una implantació sòlida reparteix responsabilitats i documenta qui decideix cada capa.
Checklist final abans de passar a producció
- [ ] el problema i la línia de base estan documentats;
- [ ] la finalitat és concreta i no s’ha ampliat durant el pilot;
- [ ] les dades estan minimitzades;
- [ ] contractes, subencarregats i regió s’han revisat;
- [ ] les sortides tenen un responsable de validació;
- [ ] els errors crítics tenen criteri d’aturada;
- [ ] les persones reben informació clara quan correspon;
- [ ] l’equip ha completat formació pràctica;
- [ ] es poden exportar dades i abandonar el servei;
- [ ] hi ha data de reavaluació;
- [ ] la decisió final i el risc residual han quedat registrats.
Preguntes freqüents
Cal començar per un xatbot?
No. Sovint és millor començar per una tasca interna de risc baix i sense dades clíniques. Un xatbot públic afegeix riscos de marca, privacitat, seguretat i resposta davant situacions inesperades.
Noranta dies són suficients?
Són suficients per a un pilot acotat i una decisió informada, no necessàriament per desplegar un ús clínic complex. Els terminis han d’augmentar amb el risc i la necessitat d’evidència.
Quina mètrica importa més?
No n’hi ha una de sola. Cal combinar temps total, qualitat, errors, risc, càrrega de revisió, experiència i capacitat de retirada. Estalviar minuts no compensa un risc greu.
Qui ha de liderar el projecte?
Una persona amb autoritat per coordinar operacions, clínica, tecnologia, privacitat i direcció. El lideratge no pot quedar exclusivament en el proveïdor ni en una persona entusiasta sense capacitat d’aturar.
Fonts i recursos
- OMS: orientacions sobre models generatius en salut
- APA: guia per avaluar assistents de notes amb IA
- APA: ús responsable d’IA en avaluació psicològica
- AEPD: mapa de tractaments que incorporen IA
- Serveis per a psicòlegs i centres
Contingut informatiu. No substitueix una avaluació clínica, jurídica, tècnica o de protecció de dades del projecte concret.
Següent pas
Compara opcions amb calma
Filtra el directori per especialitat, modalitat, municipi i idioma, i revisa la informació pràctica abans de contactar-hi.
Veure serveis per a psicòlegs
