Datakartan för röst-AI: inspelningar, transkript, API:er och återskrivning till CRM

En datakarta för röst-AI är en enda sida som listar varje artefakt ett samtal skapar, var den lagras, hur länge den sparas, hur den lämnar plattformen och vilka av dina system den hamnar i. Säkerhetsteamet efterfrågar den innan avtalet skrivs under, och IT och drift använder den för att planera integrationen.

Den här guiden bygger den kartan för Retell AI utifrån dokumentationen från Retell. Där dokumentationen inte säger något får du veta vad du ska fråga.

Vilken data skapar ett enda röst-AI-samtal?

Ett kopplat samtal i Retell ger sju typer av data, alla samlade i ett samtalsobjekt som identifieras med call_id:

• Inspelning. WAV-ljud, både som en mixad enkanalsfil och som en flerkanalsfil där varje part har en egen kanal.
• Transkript. Ren text, en lista med yttranden och tidsstämplar samt en version där varje verktygsanrop och dess resultat är invävda.
• Analys efter samtal. Inbyggda fält (call_summary, user_sentiment, call_successful, in_voicemail) plus anpassade fält som du definierar som boolean, text, nummer eller väljare.
• Loggar. En offentlig logg över LLM-förfrågningar och svar, plus en hämtningslogg för kunskapsbasen om agenten använder en.
• Variabler och metadata. Dynamiska variabler som skickas in eller samlas in under samtalet, samt ett fritt metadata-objekt för dina egna ID:n.
• Telefonnummer. Nummerpresentationen för inkommande samtal och det uppringda numret för utgående samtal.
• Driftfält. Tidsstämplar, längd, status, orsak till frånkoppling, överföringsdestination, latens och kostnad.

De flesta av dessa är tillgängliga först när samtalet har avslutats, och anpassade analysfält förblir tomma för samtal som aldrig kopplades fram.

Var finns varje del, och hur får du ut den?

Allt finns i samtalsposten i din Retell-arbetsyta och lämnar den via tre utgångar: webhooks, API:et och CSV-exporter från dashboarden.

Fyra detaljer spelar roll när du kopplar ihop det här:

• List Calls utelämnar transkript och recording_url för att hålla svaren små, så en massåterfyllning kombinerar den med Get Call per call_id.
• Webhooks får timeout efter 10 sekunder och görs om upp till 3 gånger, så deduplicera på call_id.
• Varje webhook har en x-retell-signature-header som du verifierar med din API-nyckel, och Retell publicerar en IP-adress att tillåtslista (100.20.5.228).
• CSV-exporter skapas i dashboarden utifrån de aktiva filtren och sparas i en vecka. List Export Requests (GET /v2/list-export-requests) returnerar varje exports status och nedladdnings-URL.

Hur länge sparar Retell samtalsdata, och kan du stänga av lagringen?

Som standard sparar Retell samtalsdata på obestämd tid. Du ändrar det per agent under Security & fallback settings.

Lagringstid. Välj 1, 3, 7, 30, 60, 90, 180, 365 eller 730 dagar, eller spara för alltid; via API:et anger du data_storage_retention_days. Utgången data raderas dagligen och permanent, vilket omfattar inspelningar, transkript, loggar, dynamiska variabler och metadata. Retell behåller viss grundläggande metadata internt, men samtalet syns inte längre i historiken eller i API-svar.

Lagringsläge. Välj ett av tre:

• Everything. Transkript, inspelningar och loggar lagras.
• Everything except PII. Innehållet lagras med dina valda PII-kategorier borttagna, och de råa originalen raderas.
• Basic Attributes Only. Inga transkript, inspelningar eller loggar lagras, och Get Call returnerar samtalet utan dem.

Om du väljer bort lagring skickar webhooks fortfarande med transkriptet och inspelningen, men inspelningslänken går ut 10 minuter efter att webhooken har kommit fram. Bygg din webhook-mottagare innan du byter.

Inställningen data_storage_setting i Update Call kan göra ett enskilt samtal striktare, aldrig mindre strikt. Behöriga dashboardanvändare kan ta bort ett samtals känsliga data eller radera samtalet, och Delete Call (DELETE /v2/delete-call/{call_id}) gör samma sak via API. Ingen av åtgärderna går att ångra.

Inspelnings- och logg-URL:er går inte ut som standard. Aktivera Opt In Secure URLs (opt_in_signed_url) så signeras varje URL du begär och går ut efter 24 timmar, eller efter en tid du själv anger mellan 1 minut och 7 dagar.

Vad tar PII-maskering faktiskt bort?

Med Everything except PII identifierar Retell de kategorier du har valt efter samtalet och ersätter varje förekomst med en numrerad platshållare, till exempel [email 1]. De 13 kategorierna är personnamn, adress, e-post, personnummer (SSN), pass, körkort, kreditkort, bankkonto, lösenord, PIN-kod, medicinskt ID, födelsedatum och kundnummer.

Rensningen omfattar mer än transkriptet: inspelningen (PII-intervall ersätts med ett pip), offentliga loggar, dynamiska variabler, metadata, samtalssammanfattningen och anpassade analysdata samt argument och resultat från verktygsanrop. DTMF-siffror blir [PII INFO] så snart någon kategori är aktiverad.

Om du väljer phone_number tas kundens nummer bort från själva samtalsposten (from_number för inkommande, to_number för utgående). Låt den vara avstängd om ett nedströmssystem matchar på det numret.

Vissa fält rensas aldrig, bland annat call_id, agent_id, tidsstämplar, status, orsak till frånkoppling, call_successful, user_sentiment, kostnad och anpassade attribut. Om du vill bli av med även dem använder du Basic Attributes Only eller en lagringstid.

Åtkomsten är rollbaserad. Rollen Member ser bara rensad historik, medan Admins och Developers kan se råa transkript och inspelningar.

Var lagras datan, och vad bör säkerhetsteamet fråga?

Compliance-dokumentationen från Retell anger att Retell uppfyller HIPAA och GDPR och är certifierad enligt SOC 2 Type 1 och Type 2, att GDPR uppfylls genom att AWS används med ett GDPR-kompatibelt personuppgiftsbiträdesavtal (Data Processing Addendum), och att Retell för närvarande inte driver tjänster inom Europeiska unionen. BAA och DPA (med EU:s standardavtalsklausuler) undertecknas på egen hand utan extra avgift, och certifikat och rapporter finns i Compliance Trust Center.

Den offentliga dokumentationen anger ingen lagringsregion per artefakt och namnger inte den underliggande lagringstjänsten, så anta ingenting. Fråga Retell skriftligt (support@retellai.com hanterar säkerhetsgranskningar, leverantörsbedömningar och listor över underbiträden) och bekräfta dina egna inställningar:

• Var bearbetas samtalsljudet, och var lagras varje artefakt i tabellen?
• Vilka underbiträden hanterar ljud, transkript och analys?
• Matchar lagringstiden och lagringsläget för varje agent i produktion vår policy?
• Är säkra URL:er aktiverade, med en giltighetstid som vi godtar?
• Vilka av våra användare har rollen Admin eller Developer och kan se rådata?
• Verifierar vår webhook-mottagare signaturer och sparar det vi behöver innan lagringstiden raderar det?

För avtalssidan (BAA kontra DPA, hinder kring datalokalisering, upphandlingssteg), se vad företagsköpare behöver veta innan de driftsätter röst-AI.

Vad når ditt CRM, och via vilken väg?

Det beror på vägen. De inbyggda integrationerna i Retell med Salesforce, HubSpot, Microsoft Dynamics 365, GoHighLevel och Zoho CRM importerar kontakter (var 5:e minut från och med augusti 2026), mappar fält från analys efter samtal till kontaktfält, skickar tillbaka fältändringar och loggar varje samtal som en aktivitet. En Salesforce-Task innehåller till exempel längd, sammanfattning, konversations-ID, telefonnummer och orsak till frånkoppling. Utgående synk uppdaterar endast befintliga poster om du inte aktiverar Create new contacts in CRM, och aktivitet loggas bara för kontakter som har importerats från det anslutna CRM:et.

Inspelningar och fullständiga transkript når CRM:et bara när vägen för med sig dem, som samtalsloggen i HubSpot Marketplace-appen eller din egen webhook-skrivare gör. För mekaniken från trigger till återskrivning, se arbetsflödet från CRM till röst-AI; integrationskatalogen listar vad som kan anslutas direkt.

Hur bildar läsningen före samtalet och skrivningen efter samtalet en testbar loop?

En integration är klar när ett samtal läser rätt post innan det börjar, bokar mötet under samtalet och skriver teknikerns anteckning efteråt, allt på samma post. Sidan Workflow för agenter i Retell modellerar detta som en enda graf. För en fältservicelinje:

1. Läsning före samtalet. En funktion före samtalet söker i CRM:et efter {{user_number}} och mappar post-ID:t till en variabel. Inkommande samtal väntar upp till 1 minut på den; utgående samtal tillåter 5 minuter innan uppringningen.
2. Bokning under samtalet. Agenten bokar med ett kalenderverktyg (Cal.com, Calendly eller GoHighLevel-kalendrar) eller en anpassad funktion som anropar API:et i ditt schemaläggningssystem, som kan verifiera headern X-Retell-Signature. Boknings-ID:t läggs i en variabel.
3. Skrivning efter samtalet. En funktion efter samtalet skapar anteckningen: verktygen för Salesforce, Dynamics 365 och Zoho skapar anteckningar, Zendesk lägger till privata anteckningar och allt annat kräver en anpassad funktion. Den återanvänder post-ID:t från före samtalet, skriver {{call_summary}} eller ett anpassat fält som access_instructions och är villkorad så att den bara körs när bokningsvariabeln finns. Funktioner efter samtalet avbryts efter 5 minuter.

Om uppslaget misslyckas hoppas alla funktioner som är beroende av det över, så ingen anteckning skrivs utan ett post-ID, och samtalet genomförs ändå. En begränsning för plattformsteam: arbetsflödesfunktioner konfigureras endast i dashboarden och ingår inte i det publika API:et (från och med augusti 2026), så de kommer inte att finnas i din infrastructure-as-code.

Testa loopen i två omgångar:

• Simuleringstester med mockar. Mocka varje anpassad funktion och varje kalenderverktyg. En funktion som inte är mockad anropar sin riktiga endpoint och kan skapa en riktig bokning.
• Ett riktigt samtal mot en sandlådepost. Ring ett testsamtal via webben eller telefon och öppna det i samtalshistoriken. Funktioner före samtalet visas under Before call och funktioner efter samtalet under Call ended, med skickade argument och returnerade svar. Godkänn bara om bokningen finns, anteckningen ligger på samma post och din mottagare har loggat en call_analyzed-händelse för just det call_id.

För den bredare pilotplanen, se hur du utvärderar en plattform för röstagenter innan lansering. För hur funktioner före och efter samtalet fungerar, se Retell Workflows.

Använd kartan i praktiken

Fyll i tabellen per agent och bifoga säkerhetssvaren, så fungerar en enda sida som underlag för din granskning, din integrationsplan och ditt revisionsspår. Om du vill se vad Retell extraherar från varje samtal och hur det flödar till dina system kan du börja med analys efter samtal i Retell.