AI trenger deres kontekst — ikke bare mer internett
Når en leder, prosjektansvarlig eller utvikler ber en AI om råd, blir svaret ofte generelt av én enkel grunn: Modellen kjenner ikke kundene, rutinene, tidligere beslutninger, systemene eller begrensningene deres. Den har mønstre fra verden, men ikke den lokale virkeligheten i virksomheten.
Dette er én av grunnene til at AI-strategi kan ende i Trendslop: Tekst som er velskrevet og tidsriktig, men for vag til å velge neste steg. Løsningen er ikke nødvendigvis et stort RAG-prosjekt. Start heller med en liten, ryddig kunnskapsbase som mennesker forstår og AI-en kan bruke med klare rammer.
En god Vault er ikke «alt vi vet». Den er den delen av kunnskapen som er oppdatert, relevant, eies av noen og kan brukes med ansvar.
Hva er en Obsidian Vault?
En Vault er i praksis en mappestruktur med noter, lenker og metadata. Obsidian bruker lokale Markdown-filer, slik at notene kan leses, flyttes og versjonsstyres uten å låse virksomheten til et bestemt skyformat. Det betyr at en Vault kan fungere både som et vanlig arbeidsområde for mennesker og som en tydelig kontekstmappe for AI.
LLM Wiki fra nashsu er et konkret åpen kildekode-eksempel. Prosjektet beskriver en desktop-applikasjon som gjør dokumenter om til en organisert, sammenlenket kunnskapsbase som vedlikeholdes gradvis av en språkmodell, i stedet for at hvert spørsmål starter med å hente og svare fra bunnen av. Wiki-mappen er oppgitt å være kompatibel med Obsidian Vault. [1]
Det er interessant fordi en virksomhet sjelden trenger «den smarteste chatboten» først. Den trenger en enkel måte å samle beslutninger, definisjoner, prosesser, kilder og åpne spørsmål på — slik at assistenten slipper å gjette.
Start med det dere allerede trenger hver uke
En Vault trenger ikke være en digital kopi av hele filserveren. Begynn med én prosess eller ett ansvarsområde der informasjon ofte må finnes igjen: kundehenvendelser, tilbud, prosjektleveranser, kvalitet, onboarding eller intern drift.
| Mappe eller fil | Eksempel på innhold | Eierskap og kvalitet |
|---|---|---|
| 00_Styring/MÅL.md | Mål, målgruppe, avgrensning og hva som skal bli bedre. | Prosjekteier oppdaterer dato og status. |
| 00_Styring/BESLUTNINGER.md | Hva som er vedtatt, hvorfor og hva som fortsatt er uavklart. | Lenke til møtereferat eller annen primærkilde. |
| 10_Prosesser/ | Godkjente rutiner, sjekklister og prosesskart. | Fagansvarlig merker «gjeldende» eller «utkast». |
| 20_Kunnskap/ | Begreper, produktinfo, leverandørnotater og eksterne kilder. | Kilde, dato og bruksområde står øverst i notatet. |
| 30_Prosjekter/ | Avgrenset kontekst for konkrete kunde- eller forbedringsprosjekter. | Prosjektleder angir tilgang, eier og arkivdato. |
En håndverksbedrift kan for eksempel starte med tilbudsrutiner og beskrivelse av tjenester. Et regnskapsmiljø kan starte med interne arbeidsrutiner og faglige avklaringer som ikke inneholder kundedata. En teknisk bedrift kan begynne med systemoversikt, driftsprosedyrer og vanlige feilsøkingsnotater. Målet er ikke å skrive alt på nytt; det er å rydde og merke det dere allerede må slå opp i.
Fra gamle dokumenter til en lesbar wiki
Her kan en løsning som LLM Wiki være nyttig. I stedet for at én lang PDF, et gammelt prosjektrom eller en mappe med møtereferater blir liggende som isolerte kilder, kan innhold trekkes ut til mindre, sammenlenkede sider. En side om «tilbudsprosess» kan peke til «kundetyper», «godkjenning av pris», «standardforbehold» og «tidligere beslutninger».
Det betyr ikke at AI-en skal erklære noe som gjeldende bare fordi den fant det i et gammelt dokument. Den nyttige arbeidsmåten er at AI-en foreslår struktur, oppsummering og lenker, mens en person med ansvar godkjenner statusen.
| Oppgave | Hva AI-en kan bidra med | Hva et menneske må kontrollere |
|---|---|---|
| Gamle prosjektmapper | Foreslå temaer, tidslinjer, begreper og sider som hører sammen. | Om dokumentet er relevant, gjeldende og lov å bruke. |
| Rutinedokumenter | Lage et utkast til kort, lenkbar prosesside med kildehenvisning. | Faglig riktighet, eier, dato og godkjenning. |
| Møtereferater | Samle beslutninger, åpne spørsmål og oppfølgingspunkter. | At beslutningen faktisk ble tatt, og hvem som eier oppfølgingen. |
| Spørsmål fra ansatte | Finne aktuelle sider og oppgi hvilke kilder som er brukt. | Når svaret blir et råd eller en handling med faglig konsekvens. |
Når flere agenter deler kunnskap
Videoer om Hermes, Paperclip og Buzz viser ofte et «Second Brain» som felles kontekst for et digitalt team. Det er en god idé bare når arbeidsdelingen er tydelig. Ikke gi alle agenter hele Vaulten. En undersøkende agent kan få lese godkjente prosessnoter, en utfører kan få en kort oppgavebrief og en reviewer kan få kriterier og kilder – uten at hver agent ser alle kundemapper, gamle utkast eller hemmeligheter.
En kanalhistorikk i Buzz eller en oppgave i Paperclip kan dokumentere hva som er gjort. Vaulten bør fortsatt være stedet der godkjente prosesser, beslutninger og kildegrunnlag vedlikeholdes. Samtaler og aktiviteter er ikke automatisk gyldig virksomhetskunnskap.
Progressiv kontekst: Ikke gi AI-en hele arkivet
En vanlig feil er å laste opp alt og be modellen «sette seg inn i virksomheten». Det gir ofte mye irrelevant kontekst, høyere kostnad og større risiko for at gammel eller sensitiv informasjon blandes inn.
Bruk heller progressiv avdekking. AI-en starter med et kort styringsnotat, henter bare relevante sider for det aktuelle spørsmålet og stopper når den mangler kildegrunnlag.
Eksempel: En person spør: «Hva må vi avklare før vi automatiserer oppfølging av nye leads?» Assistenten leser først MÅL.md og BESLUTNINGER.md. Den henter deretter bare den godkjente beskrivelsen av lead-prosessen, CRM-feltene og kundekommunikasjonen. Hvis den ikke finner en oppdatert regel for samtykke eller ansvar ved utsending, skal den markere dette som et åpent spørsmål — ikke finne på en policy.
Dette er samme tankegang som i Anti-Trendslop-skillen: lite, ferskt og høy-signal kontekst før brede påstander. [2]
Vault først, RAG når behovet faktisk kommer
RAG kan være riktig når dere har mange dokumenter, hyppige oppdateringer eller behov for å finne små utdrag i et stort arkiv. Men RAG er ikke en oppryddingstjeneste. Et RAG-oppsett kan fortsatt hente et gammelt utkast, en feil policy eller en kilde personen ikke har tilgang til hvis metadata og tilgang ikke er på plass.
| Situasjon | Start med | Neste steg når det trengs |
|---|---|---|
| Ett team, få arbeidsprosesser | En liten Vault med godkjente Markdown-sider. | Bruk AI til å lenke, oppsummere og finne åpent arbeid. |
| Mange historiske dokumenter | LLM Wiki eller lignende for å foreslå struktur og bygge sider gradvis. | Etabler eiere, status og arkivregler før bred AI-tilgang. |
| Større arkiv med mange ansatte | Vault som styringslag, tydelige metadata og tilgangsgrupper. | RAG med tilgangsfilter, kildehenvisning, evaluering og logging. |
| Data som endres fra time til time | Korte styringsnoter for prinsipper. | Hent ferske fakta fra godkjent system med synlig tidspunkt. |
Koble Vaulten til 4D før dere gir en agent oppgaver
En Vault gjør konteksten bedre, men den bestemmer ikke hva agenten skal få lov til å gjøre. Bruk derfor 4D-rammeverket før dere kobler Vaulten til Claude, en lokal modell eller en bakgrunnsagent.
| 4D | Eksempel med Vault |
|---|---|
| Delegering | «Finn motstridende beskrivelser av tilbudsprosessen og lag en oversikt.» Ikke «rydde hele arkivet». |
| Beskrivelse | Angi tillatte mapper, tidsperiode, kvalitetssignal og ønsket leveranse. |
| Dømmekraft | Krev kildehenvisning, usikkerhetsmarkering og review fra prosesseier. |
| Aktsomhet | Avklar at agenten ikke skal dele, slette, endre eller bruke begrenset innhold uten spesifikk godkjenning. |
Personvern og sikkerhet: Lokal fil er ikke automatisk trygg fil
En Vault er bare så trygg som enheten, synkroniseringen, tilganger og tjenestene som får lese den. Ikke legg personopplysninger, lønnsdata, helseopplysninger, hemmeligheter eller kundedokumenter inn i et AI-arbeidsløp uten at dere vet hvor data behandles, hvem som har tilgang og hva som logges.
Start derfor med ikke-sensitive eller nøye avidentifiserte dokumenter. Kartlegg tilgang før dere gir en AI-assistent leserettigheter, hold skrive- og sletterettigheter adskilt fra søk, og behold menneskelig godkjenning når svaret kan påvirke kunder, ansatte, økonomi eller sikkerhet. Lokal AI kan være aktuelt i enkelte tilfeller; offline AI-artikkelen forklarer hvorfor dette likevel ikke fritar virksomheten fra ansvar for sikkerhet og personvern.
En forsiktig start dere kan gjennomføre på to uker
Uke 1: Velg én arbeidsprosess og finn fem til ti pålitelige kilder. Lag mappestrukturen, skriv et kort MÅL.md og merk hvert dokument med eier, status og dato. La AI foreslå sammendrag og koblinger, men få fagansvarlig til å godkjenne dem.
Uke 2: Formuler fem reelle spørsmål fra hverdagen. Sammenlign svar fra en tom chat med svar som bruker bare den godkjente Vaulten. Vurder om svaret viser riktig kilde, passer deres begrensninger, markerer usikkerhet og gir et neste steg noen kan eie. Forbedre én ting om gangen.
Da har dere ikke bare «gitt AI-en dokumenter». Dere har begynt å bygge en kunnskapsbase som gjør mennesker og AI bedre i stand til å forstå hva virksomheten faktisk har bestemt og hvordan arbeidet skal gjøres.
Kilder
[2] Kakushin — Anti-Trendslop Skill
