AI i CMS: vad det faktiskt gör, och vad du bör fråga först

”AI i CMS” betyder i dag tre olika saker med mycket olika värde. Håll isär dem innan du tar ställning.

Tre olika saker som kallas samma

Skrivhjälp i redigeraren. Förslag på rubrik, omskrivning av ett stycke, översättning. Det är den vanligaste formen och den minst omvälvande — samma funktion som finns i en ordbehandlare, fast närmare innehållet.

Automatik på strukturen. Att generera alt-texter, föreslå taggar, fylla metafält, hitta dubbletter. Mindre glamoröst och betydligt mer användbart, eftersom det är arbete ingen redaktör gör frivilligt men alla saknar när det inte gjorts.

Agenter som utför uppgifter. Att beskriva vad som ska hända med en mängd innehåll och låta systemet göra det. Kraftfullast och mest riskabelt, för samma anledning: det som går fort går fort åt båda hållen.

Vad vi själva kör

Alla tre finns i vår egen Studio, men de väger olika tungt.

Skrivhjälpen använder vi minst. Sanitys content agent skapar utkast åt oss när det finns ett tydligt underlag att utgå från, och den kräver ingen installation — alla med en tillräckligt ny Studio har den. Men ett utkast är en utgångspunkt, inte en text.

Agent Actions använder vi desto mer. En av våra utvecklare har byggt en inkorg till Studion och släppt den som öppen källkod, sanity-plugin-structure-inbox. Vi kör den i vår egen Studio, där den gör den tomma startvyn till en lista över smått som väntar på någon: obesvarade förfrågningar, trasiga länkar, bilder utan alt-text, utkast som blivit liggande. Agenten kan sammanfatta läget, bedöma om ett utkast är redo att publiceras och föreslå vad som bör göras härnäst.

Två val i pluginen säger mer om var vi tycker AI hör hemma än någon princip vi kan formulera. Varje AI-läsning är något en redaktör klickar på, aldrig något som händer av sig självt. Och massåtgärderna kostar aldrig något: knappen som fixar många rader på en gång gör bara det pluginen kan räkna ut själv. Ett anrop till Agent Actions går på fem cent. Det är inte mycket, men det är inte noll, och skillnaden mellan något som är gratis och säkert och något som kostar och gissar bör synas i gränssnittet.

Det som gjorde sammanfattningarna användbara visade sig för övrigt inte vara modellen, utan en rad text i konfigurationen som beskriver vad företaget är och vilka kunderna är. Utan den kan en sammanfattning bara beskriva raderna framför sig. Med den kan den säga varför en rad spelar roll.

Vid sidan av det kör vi Sanity Functions, som inte har med AI att göra: kod som körs på innehållshändelser snarare än på scheman. När något publiceras invalideras cachen på de sidor som berörs, automatiskt. En annan funktion letar trasiga länkar genom hela innehållet och rapporterar in dem i samma inkorg.

De två sista är inte AI, och löser ändå precis den sortens problem som brukar hamna på en AI-önskelista: håll innehållet aktuellt, hitta fel ingen orkar leta efter manuellt. Poängen är inte att AI vore fel — det är att frågan ”vad ska automatiseras?” är mer intressant än frågan ”var ska AI sitta?”

Vad man bör fråga sig innan man slår på något

• Vem granskar resultatet? Genererad alt-text som ingen läser är sämre än ingen alt-text, för den ser färdig ut.
• Går det att se vad som var maskinellt? Om ett halvår, när någon undrar varför en text ser ut som den gör.
• Vad händer när det blir fel i skala? En agent som taggar fem dokument fel är ett irritationsmoment. Femhundra är ett projekt.
• Löser det ett problem ni faktiskt har? Redaktörer klagar sällan på att det är svårt att skriva. De klagar på att det är svårt att hitta, strukturera och underhålla.

Vårt svar, tills vidare

Vi bygger med Sanity för att innehållet är strukturerat och går att komma åt programmatiskt — vilket gör automatik möjlig oavsett om den är AI-driven eller inte. Den ordningen känns rätt: strukturen först, verktygen sedan.