Innan AI får läsa nästa datakälla: fyll i ett anslutningskort

AI-verktyg blir snabbt mer lockande när de kan läsa riktiga system. En supportassistent som hittar rätt artikel själv. En researchassistent som kan slå i produktdokumentation. En intern hjälpreda som kan söka i filer, ärenden och externa kunskapskällor.

Det är bra. Det är också precis där många organisationer behöver ett extra steg före "slå på".

Google lade nyligen till nya datakällor i Gemini Enterprise Business edition: Apollo Graph OS, Clinical Trials, Crypto, Excalidraw, GoDaddy, Hugging Face, Microsoft Learn och Trivago. Flera är markerade som read-only. Samma hjälpsida säger att Gemini Enterprise bara når det användaren uttryckligen godkänner, och att filhantering via anslutningar har en gräns på 50 MB.

Källa: Gemini Enterprise Business edition release notes

Källa: Connect your Google apps and third-party data

Read-only låter tryggt. Men read-only betyder inte: ingen ägare, ingen felplan, ingen fråga om vilka svar AI:n får bygga på källan. Därför gillar jag ett enkelt anslutningskort: en sida som ni fyller i innan AI får en ny datakälla.

Ett anslutningskort är inte mer policyarbete

Det är motsatsen. Det är ett sätt att slippa långa policytrådar när något redan används.

Skriv kort, helst på en sida:

• Vilken datakälla kopplas in?
• Vilket jobb ska AI:n hjälpa till med?
• Vem äger källan och behörigheten?
• Är kopplingen bara läsande, eller kan den skapa, ändra, skicka eller ladda ner något?
• Hur färsk måste informationen vara för att svaret ska vara användbart?
• Vilken människa granskar resultatet innan det når kund, elev, patient, leverantör eller ledning?
• Vad säger ni när kopplingen inte fungerar?
• Hur stänger ni av eller backar kopplingen?

Det räcker långt. Poängen är inte att göra kopplingen långsam. Poängen är att veta vad ni just kopplade in.

Read-only kan fortfarande ge fel svar

En läsande koppling kan ändå skapa problem. AI:n kan hämta föråldrad dokumentation. Den kan hitta en sida som är tekniskt korrekt men irrelevant för kundens situation. Den kan missa att en fil är för stor för att hanteras. Den kan bygga ett svar på en källa som bara en viss användare egentligen får se.

Det gör inte kopplingen dålig. Det gör den mänsklig nog att behöva rutiner.

Ett bra anslutningskort fångar därför tre saker som ofta glöms bort:

• Begränsning: filstorlek, behörighet, licenskrav, språk, region eller data som inte ska användas.
• Färskhet: hur ofta källan uppdateras och när AI:n ska säga "jag vet inte" i stället för att gissa.
• Synlighet: var det går att se att kopplingen användes, vem som godkände den och vilket svar den påverkade.

Felmeddelandet ska handla om steget, inte om "AI"

Mistrals statusflöde visar varför det här behövs. Den 23 maj hade Mistral flera korta, lösta incidenter i Conversations API, Integrations API-kopplingar som code_interpreter och image_generation, samt OCR API. Det var inte samma sak som att "Mistral var nere". Det var specifika steg i AI-arbetsflöden som krånglade.

Källa: Mistral AI status activity

Källa: Mistral incident: Connector code_interpreter Degraded

För en verksamhet som använder AI till dokumentintag, research, kodanalys eller bildutkast spelar skillnaden roll. Säg inte "AI är trasig" om OCR-steget inte läser dokument. Säg: "Dokumenttolkningen är försenad. Vi kör manuell kontroll för de här ärendena och uppdaterar igen klockan 14."

Det är mycket lugnare. Det är också mer sant.

Kopiera den här mallen

Använd den här versionen som start. Byt ord så att den passar ert arbete.

1. Datakällan

Namn på källan:

Ägare:

Vilken typ av information finns här?

Finns känsliga uppgifter, kunddata, elevdata, personuppgifter eller avtal?

2. Jobbet AI ska hjälpa till med

AI:n ska använda källan för att:

AI:n får inte använda källan för att:

Svaret måste granskas av:

3. Behörighet och beteende

Kopplingen är bara läsande, läsande och skrivande, läsande och skickande, eller osäker tills någon har testat. Skriv vilket alternativ som gäller.

Vilka användare får aktivera den?

Vilka filer eller objekt ska aldrig skickas vidare?

Finns filstorleksgräns, exportgräns eller licenskrav?

4. Färskhet och källkvitto

Hur gammal får informationen vara?

Ska AI:n visa källa, länk eller filnamn i svaret?

När ska AI:n svara "jag behöver en människa"?

5. Felplan

Om kopplingen inte fungerar gör vi så här:

Meddelande till kund eller intern användare:

Manuell reservrutin:

Statussida eller supportkanal att kontrollera:

Vem bestämmer när vi pausar kopplingen?

6. Avstängning

Så tar vi bort behörigheten:

Så hittar vi svar eller filer som redan skapats med källan:

Så informerar vi berörda personer om kopplingen ändras:

Ett litet exempel

Säg att en utbildningsverksamhet vill låta AI läsa externa kursdokument och interna rutiner för att hjälpa personalen svara snabbare på frågor.

Utan anslutningskort blir frågan lätt: "Funkar kopplingen?" Med anslutningskort blir frågan bättre:

• Får AI:n bara läsa materialet, eller får den också skapa utkast till mejl?
• Vilken källa vinner om den interna rutinen säger något annat än den externa dokumentationen?
• Måste svaret visa länk till källan?
• Vem äger svaret om kopplingen är nere och personalen använder en manuell mall?

Det är där nyttan börjar. Inte i ännu en knapp. I att kopplingen får en ägare och en reservväg.

När Hammer kan hjälpa

Om ni redan använder AI mot filer, SaaS-system, kundhistorik eller externa kunskapskällor kan ett anslutningskort bli första delen av en tryggare rutin. Tool Forge passar när själva arbetsflödet ska byggas eller testas. Mindset Forge passar när ni behöver bestämma gränser, roller och språk innan fler får tillgång.

Börja litet: välj en koppling som redan känns nyttig, fyll i kortet ovan och testa vad som händer när källan saknas, är för gammal eller ligger nere. Det testet säger mer än ännu en demo.