La primera pregunta ha d'arribar abans que l'eina. Davant d'una resposta automàtica, la qüestió inicial no és quant temps estalvia, quants missatges classifica ni quina aparença d'intel·ligència ofereix. La qüestió és quina necessitat atén, quin dany pot causar si s'equivoca, qui tindrà una sortida quan no entengui la resposta i qui respondrà per la decisió. Aquest manifest proposa una regla senzilla per a la intel·ligència artificial quotidiana: cap automatització no ha d'ocupar el lloc d'una pregunta humana ben formulada.
L'automatització ja intervé en gestos corrents. Ordena correus, recomana horaris, filtra sol·licituds, redacta esborranys, tradueix avisos i decideix quina informació apareix primer. Per aquesta proximitat sembla neutral. Tanmateix, cada resposta automàtica fixa prioritats, pressuposa dades i converteix una situació complexa en una categoria. El problema no viu només en els grans sistemes ni en els titulars extraordinaris. També és en la resposta breu que arriba a una persona preocupada, en el formulari que interpreta una absència com a error i en l'assistent que ofereix una solució convincent sense conèixer el context.
Preguntar abans d'automatitzar#
La pregunta prèvia ha de descriure el problema sense vendre una resposta per endavant. Pot ser: «quina tasca es retarda i per què?», «quina informació necessiten realment les persones?», «quina part necessita judici, empatia o responsabilitat?». Preguntar així evita que una eina es converteixi en la definició del problema. Si una oficina rep moltes consultes repetides, potser cal millorar una pàgina, aclarir una carta o ampliar un horari d'atenció. Instal·lar un xatbot pot ser adequat en alguns casos, però no és la resposta automàtica per defecte.
La pregunta prèvia ha de descriure el problema sense vendre una resposta per endavant.
Una bona pregunta també anomena el límit. Hi ha decisions que no s'haurien de delegar en un sistema que infereix patrons: una urgència sanitària, una sol·licitud de suport social, una denúncia de discriminació o una situació laboral delicada requereixen persones capaces d'escoltar, demanar aclariments i assumir responsabilitat. La rapidesa pot ser valuosa, però no equival a la cura. Quan el cost d'un error recau en qui ja té menys temps, menys recursos o menys accés a ajuda, l'estàndard ha de ser més alt.
Abans de posar una eina en marxa convé escriure una fitxa breu: propòsit concret, persones afectades, dades emprades, resposta prevista, riscos coneguts, via humana i data de revisió. Aquesta fitxa no necessita llenguatge tècnic per ser útil. Obliga que la promesa d'eficiència s'enfronti a les condicions d'ús. També permet explicar a qui rep el servei per què existeix una automatització i què pot fer si no funciona. Una eina sense propòsit delimitat tendeix a estendre's cap a tasques per a les quals no s'ha avaluat.
Cas 1: el missatge que semblava una resolució#
Una entitat d'habitatge va incorporar un assistent per respondre preguntes freqüents sobre ajuts al lloguer. El sistema reconeixia paraules com «documents», «termini» i «rebuig», i retornava enllaços a pàgines informatives. En les primeres setmanes va reduir una part de les trucades. Després, diverses persones van interpretar les respostes com una resolució oficial: en llegir que faltava un justificant, van deixar de presentar la sol·licitud; en llegir que un termini havia acabat, no van preguntar per una excepció prevista a la norma. La frase automàtica era clara, però no tenia autoritat per tancar aquelles situacions.
La revisió va començar amb una pregunta diferent: «què necessita saber una persona per no perdre un dret per interpretar malament una resposta?». Es va canviar el text d'obertura per aclarir que l'eina oferia orientació general, no decisions. Les preguntes sobre denegacions, terminis vençuts i documentació incompleta passaven directament a un canal atès per personal. Cada resposta automàtica incloïa la data d'actualització i un enllaç visible per demanar revisió. Durant dos mesos es van revisar els contactes derivats, les sol·licituds abandonades i les correccions fetes per l'equip.
El cas mostra que la transparència no consisteix a afegir una etiqueta diminuta que digui «generat per IA». Consisteix a dissenyar la resposta perquè ningú no hagi d'endevinar-ne l'abast. Si una frase pot influir en l'accés a un dret, ha d'indicar què sap, què no sap i com obtenir una comprovació humana. L'automatització va continuar fent una funció limitada, però va deixar d'aparentar una decisió que no podia prendre.
Cas 2: la prioritat calculada que amagava una urgència#
Un servei de manteniment va utilitzar un sistema per ordenar avisos rebuts des d'una aplicació. El model donava prioritat a incidències amb certes paraules i a zones amb més avisos recents. La intenció era organitzar millor la feina. Tanmateix, un avís sobre una rampa malmesa va quedar avall perquè la descripció era breu i no coincidia amb els termes associats a risc. Qui el va enviar escrivia des d'un telèfon amb poca bateria i no va adjuntar una fotografia. La classificació semblava objectiva, tot i que havia convertit una manca de detalls en una manca d'importància.
La pregunta correcta no era «com es millora la puntuació del model?», sinó «quina mena d'avís no pot esperar que el model estigui segur?». Es van definir categories de seguretat que mai no es resolien només amb classificació automàtica. Els avisos ambigus entraven en una cua de revisió ràpida, i l'aplicació permetia marcar una barrera física amb poques paraules o mitjançant una trucada. L'equip va publicar el criteri de prioritat i va conservar un registre dels canvis, sense desar més dades personals de les necessàries.
La correcció no va eliminar tota automatització. La va usar com a suport per ordenar feina repetitiva, no com a permís per ignorar la incertesa. A més, es van mesurar els temps de revisió d'alertes ambigües, les incidències reobertes i els avisos arribats per canals alternatius. Un sistema responsable no presumeix de conèixer el món amb una puntuació. Reconeix quan li falta context i lliura la situació a algú que el pot obtenir.
Cas 3: l'esborrany ràpid que canviava el to#
Un equip d'atenció va començar a usar una eina generativa per redactar respostes a reclamacions. L'esborrany estalviava minuts i mantenia un estil ordenat. No obstant això, diverses contestacions van començar a repetir fórmules com «lamentem les molèsties» al costat d'explicacions massa segures sobre fets que encara s'investigaven. Algunes persones rebien un text correcte en gramàtica i fred en sentit: no reconeixia la dificultat concreta ni explicava què passaria després. La velocitat d'escriptura havia desplaçat la responsabilitat de comprovar el contingut.
L'equip va acordar que cap esborrany no es podia enviar sense lectura humana i que les reclamacions amb dany, urgència o possible discriminació no es redactarien amb plantilles generatives. Es va crear una llista de comprovació: confirmar fets, retirar afirmacions no verificades, usar llenguatge clar, indicar el pas següent i anomenar una persona o canal de resposta. Les mostres es revisaven periòdicament per detectar errors, to inadequat i referències inventades. També es va informar l'equip que l'ús de l'eina no serviria per mesurar productivitat individual.
La lliçó no és que un esborrany sigui sempre inacceptable. És que un text automàtic no té l'obligació moral ni administrativa de respondre per les seves paraules. Aquesta obligació continua sent institucional. Un bon procés aprofita l'ajuda mecànica per a tasques de risc baix i conserva temps humà per escoltar, contrastar i reparar. Quan una organització respon amb una màquina, ha de poder explicar qui ha revisat la resposta i com es pot corregir.
Dissenyar sortides, no carrerons#
Tota resposta automàtica ha d'incloure una sortida clara. No n'hi ha prou amb un botó amagat ni amb una adreça genèrica que mai no rep resposta. La sortida ha de ser accessible des del mateix moment que apareix la resposta, funcionar en mòbil, admetre llenguatge senzill i no exigir repetir tota la història. Pot consistir a parlar amb una persona, demanar revisió, desar el cas per més endavant o usar un canal no digital. Triar una via humana no s'ha de tractar com un fracàs de qui usa el servei ni com una excepció costosa que cal desanimar.
Les sortides importen especialment quan el sistema treballa amb dades incompletes. Un model pot confondre noms, interpretar malament una expressió local, no reconèixer una necessitat d'accessibilitat o respondre amb informació antiga. La persona afectada no ha de saber quin error tècnic ha passat per demanar ajuda. N'hi ha prou que pugui dir «això no respon a la meva situació». Aquesta frase ha d'obrir una revisió, no un altre bucle d'opcions automàtiques.
L'accessibilitat és part d'aquesta responsabilitat. Una interfície que només accepta text llarg exclou qui necessita trucar; una explicació amb paraules tècniques exclou qui no coneix el procediment; un termini breu exclou qui depèn de suport. Cal provar les respostes amb dispositius, idiomes, lectors de pantalla, connexions i circumstàncies de temps diferents. La prova no busca mesurar l'habilitat de les persones. Busca descobrir on el servei demana una càrrega innecessària i com la pot reduir.
També cal protecció de dades. La comoditat d'enganxar una consulta completa en una eina externa pot exposar informació que no era necessària per obtenir un esborrany. S'han d'usar només les dades indispensables, explicar la finalitat, limitar els accessos i establir terminis de conservació. Les converses sensibles no han de convertir-se en material d'entrenament o avaluació sense una base clara i una informació comprensible. La minimització no és un obstacle per a la innovació: és una manera d'impedir que una resposta útil avui generi un risc silenciós demà.
Governar la resposta quotidiana#
Governar no vol dir produir un document extens que ningú consulta. Vol dir assignar responsabilitats visibles. Cada eina necessita una persona o equip responsable del seu propòsit, de les actualitzacions i de la recepció d'incidències. Hi ha d'haver un calendari de revisió proporcional al risc i una manera de pausar el sistema si apareixen errors greus. Els registres han de permetre reconstruir quina versió es va usar, quines regles estaven actives i com es va corregir una resposta, sense convertir el seguiment en vigilància de persones usuàries o treballadores.
L'avaluació ha de mirar més que la precisió tècnica. Convé preguntar quantes persones van trobar una sortida humana, quantes respostes es van corregir, qui va abandonar el procés, quins grups van tenir més dificultats i quin dany es va evitar gràcies a una revisió. Els nombres no expliquen sols les causes, per tant s'han de combinar amb converses voluntàries i segures. Si una automatització redueix temps per a la majoria però augmenta barreres per a una minoria, aquest resultat no és un èxit complet.
La informació pública ha de ser proporcional i entenedora. Una organització pot explicar quina tasca ajuda el sistema, quines dades utilitza en termes generals, quines decisions no pren i com demanar revisió. No cal revelar detalls que facilitin abusos, però tampoc no es pot demanar confiança cega. L'explicació serveix per corregir expectatives, detectar errors i permetre un debat informat. L'opacitat sol protegir l'eina; la transparència útil protegeix les persones.
Aquest manifest defensa una pràctica concreta: aturar-se abans d'afegir intel·ligència artificial a un flux de treball i formular la pregunta que l'eina no pot formular per ella mateixa. A qui ajuda? A qui pot perjudicar? Què passa quan falla? Qui escolta? Quan es revisarà? Les respostes no sempre portaran a automatitzar. De vegades portaran a simplificar una norma, contractar suport, millorar un text o mantenir una conversa. Aquesta possibilitat no és un retard: és la condició d'una decisió responsable.
Fonts institucionals per sostenir aquest criteri.
El NIST AI Risk Management Framework ofereix un marc per governar, mapar, mesurar i gestionar riscos de sistemes d'intel·ligència artificial. L'OCDE recull principis sobre sistemes robustos, transparents i centrats en les persones. La Comissió Europea explica el marc regulador europeu d'intel·ligència artificial. La UNESCO presenta la recomanació sobre l'ètica de la intel·ligència artificial i la protecció de drets.
Aquestes fonts no substitueixen la responsabilitat de cada servei. Ofereixen un llenguatge comú per reconèixer riscos, documentar decisions i revisar conseqüències. La pràctica decisiva continua sent local: escoltar qui rep la resposta, permetre qüestionar una classificació i canviar el procés quan l'evidència ho exigeix. La intel·ligència artificial quotidiana serà més digna de confiança quan no es presenti com una autoritat inevitable, sinó com una ajuda limitada, revisable i situada.
La primera pregunta ha d'arribar abans que l'eina perquè una resposta automàtica mai no està sola. Porta una elecció sobre temps, atenció, dades i poder. Formular aquesta pregunta obre espai per a la cura; ometre-la deixa que l'eina decideixi quin problema mereix existir. El manifest acaba on ha de començar cada projecte: amb una pregunta suficient per protegir les persones abans d'accelerar el sistema.
