Viktigaste slutsatserna
- Att bygga själv betyder att välja, koppla ihop och driva compute, databas, versionering, övervakning, åtkomststyrning och revisionsspår, inte bara att anropa en modell.
- Även med molntjänster byggda för agenter behöver du sannolikt fortfarande välja, dimensionera, säkra och koppla ihop databas, nätverk, behörigheter och larm.
- Den avgörande frågan är vem i bolaget som äger stacken efter lanseringen och vad som händer när den personen slutar.
- En plattform kan ta bort jobbet att sätta ihop infrastrukturen, men inte verksamhetsarbetet med att koppla in system och bestämma vilka fall som räknas som undantag.
- Att bygga hos en molnleverantör är rätt val när du har egna utvecklare som vill bygga och styra varje komponent.
Vad det kräver att driva en AI-agent på AWS själv
Att köra en AI-agent i produktion på AWS innebär att du sätter ihop flera tjänster och driver var och en av dem efter lanseringen. Själva modellanropet är ofta den mindre delen: resten handlar om var agenten körs, var datan ligger, hur ändringar spåras och vem som får göra vad.
AWS beskriver fördelningen i sin modell för delat ansvar. Den som startar en Amazon EC2-instans sköter gästoperativsystemet, inklusive uppdateringar och säkerhetspatchar, och konfigurerar brandväggen för varje instans. Kunden ansvarar också för sin egen data och använder IAM-verktyg för att sätta behörigheter.
Det finns även tjänster specifikt för agenter. Amazon Bedrock AgentCore beskriver en runtime med sessionsisolering och inbyggd identitet, och en observability-vy där du kan spåra agentens körväg och granska dess mellanresultat. Även med dem behöver du sannolikt fortfarande välja, dimensionera, säkra och koppla ihop resten: databasen, nätverket, behörigheterna och larmen.
Jämförelsen utgår från AWS eftersom det är deras dokumentation som har kontrollerats. Ska du bygga på Google Cloud eller Azure, gå igenom deras egen dokumentation för de tjänster för compute, databas och övervakning som du behöver sätta ihop.
Exempel (illustrativt): en agent som flaggar avvikande order från Monitor G5
| Dimension | Bygga hos en molnleverantör: det du skaffar och äger själv | Ronja: det som ingår i plattformen och runtime |
|---|---|---|
| Compute | Välj var agenten ska köras, dimensionera den och håll operativsystem och beroenden patchade. | Compute ingår i plattformen. Här skulle runtime köra ordergenomgången som ett arbetsflöde som startas av en tidsstyrning, till exempel varje natt, eller av en händelse. |
| Hosting | Driftsätt agenten och en eventuell granskningsvy, och konfigurera nätverks- och brandväggsregler för var och en. | Hosting ingår i plattformen. En granskningsvy för flaggade order skulle vara en applikation som ditt team öppnar och som körs av samma runtime. |
| Managed Postgres och lagring | Välj, dimensionera, säkra och säkerhetskopiera en databas för order och flaggade avvikelser. | Order och flaggade avvikelser skulle ligga i managed Postgres och datalager, i samma grund som compute och hosting. |
| Koppling till Monitor G5 | Bygg och underhåll integrationen, inloggningsuppgifterna och datamappningen själv. | Ronja har en integration mot Monitor ERP, och Presso kör Ronja på data från Monitor G5. Behörigheter i källsystemet, datamappning och avstämning är fortfarande nödvändiga steg. |
| Versionering | Spåra ändringar i kod, promptar och konfiguration, och ha ett sätt att rulla tillbaka. | Versionering är inbyggd i den runtime som kör både ordergenomgången och granskningsvyn. |
| Övervakning | Sätt upp spårning och larm så att en misslyckad nattkörning upptäcks. | Övervakning är inbyggd i samma runtime som kör nattkörningen. |
| Behörigheter | Definiera behörigheter för personer och tjänster, och se över dem när personalen byts ut. | Åtkomststyrning är inbyggd i den runtime som kör arbetsflödet och granskningsvyn. |
| Granskningshistorik | Bestäm vad som ska loggas och hur länge, så att du kan visa vad agenten har gjort. | Revisionsspår är inbyggt i runtime, så att du kan följa vad som hände i den körning som flaggade en order. |
Vem som skulle äga och förvalta en egenbyggd stack
I ett bolag utan utvecklare hamnar en egenbyggd stack oftast hos den som satte upp den: IT-chefen som redan sköter affärssystemen, eller en extern konsult. Arbetet tar inte slut vid lanseringen, eftersom patchar, ändrade behörigheter, misslyckade körningar och nya modellversioner fortsätter att komma.
Det löpande ägarskapet är ofta den större kostnaden att väga in. Ställ konkreta frågor: vem märker när orderdatan från affärssystemet byter format, vem godkänner en ny användare, vem kan förklara förra månadens flaggade order för ekonomichefen, och vad händer när den personen går vidare? Om det ärliga svaret är ett enda namn hänger agenten på en person.
Konsulter kan bära bygget, men då ligger ägarskapet delvis i ett avtal. Avtalet bör därför ange vem som driver, övervakar och ändrar agenten efter leverans, och hur du tar över den om du byter leverantör.
På Ronja är åtkomststyrning, versionering, övervakning och revisionsspår en del av runtime, så ditt team behöver inte sätta ihop dem. Du behöver fortfarande någon som äger processen och godkänner de beslut som spelar roll.
Kontroll, ägarskap och var datan finns: tre vägar jämförda
| Dimension | Bygga hos en molnleverantör | Konsulter bygger och driver | Använda Ronja |
|---|---|---|---|
| Infrastruktur du sätter ihop och driver | Varje komponent, som drivs av ditt team eller av den du anlitar. | Det konsulten sätter ihop, som drivs så länge avtalet löper. | Runtime ingår i plattformen och omfattar åtkomststyrning, versionering, övervakning och revisionsspår. |
| Godkännanden | Godkännandesteg är oftast något du själv designar och bygger. | Beror på vad konsulten bygger och vad avtalet anger. | AI tolkar det som kräver tolkning, deterministisk kod räknar och validerar, och människor godkänner viktiga beslut. |
| Var datan lagras | På AWS bestämmer du var datan lagras, inklusive geografisk region. | Beror på vilket moln och vilken region konsulten väljer. | Ronjas publika säkerhetsbeskrivning anger behandling inom EU/EES som standard. |
| Överföring utanför EES | AWS anger att kunder kan föra över data till länder utan beslut om adekvat skyddsnivå, inklusive USA, i enlighet med GDPR, så din uppsättning avgör. | Kontrollera vilka tjänster och underleverantörer konsulten använder. | Fråga hur standarden med EU/EES gäller för din uppsättning. |
| Rätt till datan | Läs leverantörens kundavtal och planera hur du ska skydda datan. | Regleras i konsultavtalet. | Kunden behåller alla rättigheter till sin data, och Ronja får bara behandla den för att leverera tjänsten. |
| Certifiering | Planera hur din egen uppsättning ska bedömas, och kontrollera vad leverantörens certifieringar omfattar. | Beror på konsulten och det valda molnet. | ISO 27001-certifierat. SOC 2 Type 2 pågår och är inte klart. |
När en plattform passar och när det är rätt att bygga hos en molnleverantör
För
- Etablerade bolag med en stabil kärna av affärssystem, CRM-system och ekonomisystem men utan eget utvecklingsteam
- IT-chefer och data- eller systemansvariga som måste kunna styra, säkra och drifta det som byggs
- Affärsansvariga som vill få bort manuellt arbete mellan systemen, en process i taget
Inte för
- Bolag med ett eget utvecklingsteam som vill bygga allt själva på AWS, Google Cloud eller Azure: där är det rätt val att bygga själv
- Team som vill styra varje infrastrukturkomponent i detalj och har folk som kan driva den
- Bolag som främst behöver ett nytt affärssystem eller CRM, inte mjukvara ovanpå systemen de redan har
Vad en plattform inte ersätter
En plattform kan ta bort jobbet att sätta ihop infrastruktur, men inte verksamhetsarbetet runt omkring. Ronja är ett agent-first moln för icke-tekniska bolag: AI-agenter bygger, kör och förvaltar din egen mjukvara ovanpå de affärssystem, CRM-system och ekonomisystem du redan har.
Ronja är inget affärssystem och ersätter inte ERP eller CRM, utan bygger ovanpå dem. Det är inte heller ett BI-verktyg, eftersom dashboards och rapporter är en del av plattformen och inte produkten, och det är ingen iPaaS: integrationerna finns för att det som byggs ska nå datan.
Att koppla in ett system kräver fortfarande insats från din sida, och någon måste bestämma vad som räknas som en orderavvikelse. Om en sådan regel behöver ge ett bestämt, deterministiskt resultat kör Ronja den som exekverbar programlogik i stället för AI-tolkning.
Att börja smalt är ett praktiskt sätt att pröva vilken väg som passar. Enligt Marta Sjögren på Paebbl började företagets partnerskap med Ronja med avgränsade case med tydlig avkastning och växte därifrån.
Om en avgränsad process som ordergenomgången är där du skulle börja, är nästa steg att gå igenom den tillsammans med Ronja.
Prata med oss
Granska en tydligt avgränsad process tillsammans med Ronja.
Prata med ossKällor
Vanliga frågor
Vem ska äga en stack för AI-agenter i ett bolag utan utvecklare?
Någon måste ansvara för patchar, behörigheter, övervakning och ändringar efter lanseringen, inte bara för själva bygget. I praktiken blir det ofta IT-chefen eller en extern konsult. Bestäm innan du bygger vem som är ägare, vem som kan gå in som ersättare och hur ansvaret flyttas om du byter konsult. Kan du inte svara på det är en plattform vars runtime redan omfattar åtkomststyrning, övervakning och revisionsspår oftast den säkrare vägen.
Är Ronja SOC 2-certifierat?
Inte ännu. Ronja är ISO 27001-certifierat, och SOC 2 Type 2 pågår men är inte klart. Om din upphandling kräver SOC 2, fråga efter aktuell status och planera utvärderingen utifrån den i stället för att utgå från att certifieringen är klar ett visst datum.
Behöver vi AI-kompetens internt för att använda en plattform?
Du behöver processkunskap mer än AI-kompetens. De viktigaste personerna är de som kan säga vilka order som räknas som undantag, vem som ska agera på dem och vem som ger åtkomst till källsystemen. Tekniskt ägarskap behövs fortfarande, men på en plattform flyttas det oftast från att sätta ihop infrastruktur till att styra det som körs på den.