Quan una comunitat digital creix més enllà del que uns quants voluntaris poden gestionar, la moderació automàtica deixa de ser un luxe i es converteix en una necessitat. No obstant, la majoria de bots de moderació actuals depenen d’una única API d’intel·ligència artificial: d’OpenAI, Anthropic o Google. En aparençia funcionen bé, però en realitat introdueixen un punt de fallada únic que contradiu la naturalesa descentralitzada de les plataformes que pretenen protegir. Si aquesta API canvia els seus termes, apuja preus o bloqueja el compte, la comunitat es queda sense defensa d’un dia per l’altre. Aquest article proposa una arquitectura resistent que combina agents d’IA, ciberseguretat i nívol distribuit per eliminar aquesta dependència.
El problema és especialment visible en protocols socials permissionless com Farcaster, on els canals creixen ràpidament i l’spam és constant. Els moderadors humans s’esgoten, així que s’implementa un bot que classifica els missatges mitjançant una crida a una API centralitzada. Al principi tot va bé, però al cap de sis mesos tot el sistema descansa sobre la bona voluntat d’un sol proveïdor. Això no és un risc hipotètic: OpenAI, Anthropic i Google han revisat les seves polítiques d’ús en múltiples ocasions en els últims dos anys, i els desenvolupadors d’eines de moderació han documentat suspensions opaques de comptes fins i tot havent implementat els endpoints oficials de classificació. La comunitat que va triar un protocol sense permís per evitar el risc de plataforma ha reintroduït aquest risc una capa més amunt, a les eines.
La solució no passa per abandonar la intel·ligència artificial, sinó per dissenyar una capa de moderació que hereti les mateixes garanties de descentralització del protocol subjacent. A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, portem anys ajudant organitzacions a construir sistemes robustos que no depenguin d’un únic proveïdor. La nostra experiència en aplicacions a mida ens ha ensenyat que la veritable resiliència neix de combinar diferents capes: computació descentralitzada per a les tasques d’inferència, orquestadors que rutinitzen els treballs i models de codi obert que qualsevol operador pot executar.
L’arquitectura que proposem té cinc components. Primer, una integració amb el client (per exemple, un compte bot de Farcaster) que vigila el canal i converteix els nous missatges en sol·licituds de moderació. Segon, un orquestador fora de la cadena que gestiona la lògica: quin model usar, quines categories de classificació, quin llindar de confiança dispara cada acció. La comunitat configura aquest orquestador. És barat d’executar perquè no realitza inferències; només les enruta. Tercer, un router de computació que, en lloc d’enviar totes les peticions a una sola API, les distribueix entre xarxes de GPU descentralitzades com Nosana. El router tria la xarxa i el mercat segons preu, cua i latència observada. Quart, els nodes d’inferència: operadors independents que executen el model obert i retornen la classificació. Des de la seva perspectiva és treball pagat normal; no necessiten saber ni importar-los que la càrrega és de moderació. Com que els missatges són públics, no hi ha problema de privacitat. Cinquè, la capa d’acció: els resultats tornen a l’orquestador, que oculta, marca, permet o envia a revisió humana.
Els modes de fallada operatius tenen respostes avorrides, i això és bona senyal. Si un node és lent, l’orquestador espera un temps i reenvia la tasca al següent. Si està desconnectat, el router deixa de seleccionar-lo. Si la xarxa està congestionada, la moderació tolera latències de segons, a diferència del xat en viu. I el mode degradat es tria deliberadament: si la inferència no està disponible, el sistema falla cap a “posar en cua per a revisió humana”, mai cap a l’eliminació silenciosa automàtica. L’autoritat de la comunitat és el sòl sobre el qual s’assenta el sistema, no una característica afegida.
Una propietat infravalorada dels models de codi obert és que la política de moderació es torna inspeccionable. La comunitat pot publicar el model exacte i el prompt que utilitza. Els membres poden dissentir, bifurcar la política o votar per canviar-la. Proveu-ho amb un classificador tancat d’un proveïdor. A més, la classificació de spam no necessita un model frontera. Models oberts com Llama Guard de Meta o ShieldGemma de Google manegen classificacions estretes amb bona precisió, i a més s’executen en maquinari de consum, que és precisament l’oferta més abundant a les xarxes de GPU descentralitzades.
Ara bé, com confiar en la classificació que retorna un operador de GPU aleatori? Una API centralitzada respon amb reputació i contracte. Una xarxa descentralitzada ha de respondre d’una altra forma. La solució ingènua és el mostreig aleatori: enviar treballs d’alt risc a dos nodes i comparar. Això ajuda contra fallades aleatòries, però no contra un adversari que aixequi diversos nodes i faci que les respostes incorrectes coincideixin. Es pot escalar a votació majoritària, però pagues N vegades per inferència i assumeixes que els nodes són independents, cosa que un atac barat vulnera primer. Afegir reputació ajuda, però el sistema de reputació requereix un auditor, i si aquest auditor és una sola part, el punt de fallada únic s’ha mogut. El mecanisme més fort és el staking i slashing: els nodes dipositen garantia i les males conductes demostrables la cremen. Però demostrar que una classificació va ser incorrecta a propòsit és difícil en una tasca subjectiva com la moderació.
La postura honesta és que, per a classificació de spam, la redundència barata més reputació és probablement suficient, perquè el cost d’una resposta equivocada és baix i recuperable, sobretot quan el mode de fallada és “ho revisa un humà” en lloc de “el contingut desapareix”. Per a judicis de major risc, la verificació d’inferència subjectiva sense recentralitzar és un problema obert. L’arquitectura descrita està dissenyada perquè els riscos es mantinguin a la zona on les respostes imperfectes d’avui són acceptables, i el sòl de revisió humana atrapa el que s’escapa.
Per descomptat, les APIs centralitzades són més barates per crida a petita escala, més ràpides, més fiables i millor documentades. Integrar-ne una és qüestió d’una tarda. Els models frontera encara superen els oberts en matisos. Si estàs construint un bot de suport per a una startup, usar computació descentralitzada seria una mala pràctica. Tot això és cert, i no toca l’argument, perquè l’argument mai va ser “guanya en rendiment”. És que aquesta classe concreta d’eina es compra per les seves garanties, no pel seu rendiment. Una comunitat que va triar un protocol resistent a la censura està expressant una preferència sobre qui pot apagar les coses. Les eines que reintrodueixen un interruptor d’apagada, una capa més amunt, no serveixen a aquesta preferència només perquè siguin més barates aquest trimestre. Es paga el cost de latència i complexitat exactament on la garantia importa, i en cap altre lloc.
A Q2BSTUDIO, entenem aquest equilibri. La nostra oferta d’IA empresarial es recolza en models oberts i arquitectures híbrides que combinen nívol AWS/Azure per a càrregues crítiques amb xarxes descentralitzades per a tasques on la resistència és clau. També integrem nívol AWS/Azure en entorns que requereixen escalabilitat i seguretat, i apliquem principis de ciberseguretat per protegir tant les dades com els punts d’integració. A més, les nostres solucions de BI/Power BI permeten monitoritzar el rendiment d’aquests sistemes en temps real, i els agents IA que dissenyem inclouen lògica de commutació i redundència per evitar punts de fallada únics.
Els bots de moderació comunitària són l’exemple perfecte d’aquesta filosofia. Les peces existeixen avui per separat: protocols socials permissionless amb comunitats reals, xarxes de GPU que lloguen capacitat ociosa a una fracció del cost dels hiperescaladors, i models oberts suficientment bons per a classificació estreta. El que falta és la capa de connexió: el patró d’orquestador i router que hem descrit, construït com a infraestructura reutilitzable i no com un bot d’un sol ús. Aquesta és la bretxa que hem de tancar. La capa del protocol s’està descentralitzant a la vista de tothom, amb discussions obertes a tot l’ecosistema. La capa d’eines és on s’està produint la recentralització silenciosa, una clau API cada vegada, sense que ningú la vigili. Aquí és on cal actuar, i els agents de moderació, on el desajust entre les garanties del protocol i les de les eines és més agut, són el lloc correcte per començar.
No es tracta de demonitzar les APIs centralitzades. Són útils, ràpides i barates per a molts escenaris. Però quan la missió d’una eina és garantir que cap tercer pugui apagar-la, dependre d’una sola API és una contradicció que hem de resoldre. L’arquitectura que presentem no és una utopia: és un disseny pragmàtic que ja podem muntar amb tecnologia actual. I a Q2BSTUDIO estem preparats per ajudar comunitats i empreses a implementar-lo, aportant la nostra experiència en aplicacions a mida, nívol i intel·ligència artificial. Perquè un bot de moderació no hauria de tenir un sol punt de fallada, igual que la comunitat que protegeix tampoc no hauria de tenir-lo.
