Datakort for stemme-AI: optagelser, transskriptioner, API'er og tilbageskrivning til CRM

Et datakort for stemme-AI er én side, der viser alle de artefakter, et opkald skaber, hvor de gemmes, hvor længe de opbevares, hvordan de forlader platformen, og hvilke af dine systemer de ender i. Sikkerhedsteamet beder om det, før der skrives under, og IT og drift bruger det til at planlægge integrationen.

Denne guide bygger kortet for Retell AI ud fra Retells dokumentation. Hvor dokumentationen ikke siger noget, fortæller guiden dig, hvad du skal spørge om.

Hvilke data skaber ét opkald med stemme-AI?

Et forbundet opkald på Retell producerer syv typer data, alle på ét opkaldsobjekt identificeret ved call_id:

• Optagelse. WAV-lyd, både som en samlet enkanalsfil og som en flerkanalsfil, hvor hver part har sin egen kanal.
• Transskription. Ren tekst, en liste over replikker med tidsstempler og en version, der er flettet sammen med hvert værktøjskald og dets resultat.
• Analyse efter opkald. Indbyggede felter (call_summary, user_sentiment, call_successful, in_voicemail) plus tilpassede felter, du definerer som boolean, tekst, tal eller vælger.
• Logs. En offentlig log over LLM-forespørgsler og -svar plus en log over hentninger fra vidensbasen, hvis agenten bruger en.
• Variabler og metadata. Dynamiske variabler, der sendes ind eller indsamles under opkaldet, og et frit metadata-objekt til dine egne ID'er.
• Telefonnumre. Nummervisningen på indgående opkald og det kaldte nummer på udgående opkald.
• Driftsfelter. Tidsstempler, varighed, status, årsag til afbrydelse, destination for viderestilling, latens og omkostning.

De fleste af disse er først tilgængelige, når opkaldet er slut, og tilpassede analysefelter forbliver tomme for opkald, der aldrig blev forbundet.

Hvor ligger hver del, og hvordan får du den ud?

Alt ligger på opkaldsposten i dit Retell-workspace og forlader det via tre udgange: webhooks, API'et og CSV-eksporter fra dashboardet.

Fire detaljer er vigtige, når du kobler det op:

• List Calls udelader transskriptioner og recording_url for at holde svarene små, så en masseindlæsning af historiske data kombinerer det med Get Call pr. call_id.
• Webhooks får timeout efter 10 sekunder og forsøges igen op til 3 gange, så dedupliker på call_id.
• Hver webhook har en x-retell-signature-header, som du verificerer med din API-nøgle, og Retell offentliggør en IP-adresse, du kan tilføje til din tilladelsesliste (100.20.5.228).
• CSV-eksporter oprettes i dashboardet ud fra de aktive filtre og opbevares i én uge. List Export Requests (GET /v2/list-export-requests) returnerer hver eksports status og download-URL.

Hvor længe gemmer Retell opkaldsdata, og kan du slå lagring fra?

Som standard gemmer Retell opkaldsdata på ubestemt tid. Det ændrer du pr. agent under Security & fallback settings.

Opbevaringsperiode. Vælg 1, 3, 7, 30, 60, 90, 180, 365 eller 730 dage, eller behold dataene for altid; via API'et sætter du data_storage_retention_days. Udløbne data slettes dagligt og permanent, herunder optagelser, transskriptioner, logs, dynamiske variabler og metadata. Retell beholder nogle grundlæggende metadata internt, men opkaldet vises ikke længere i historikken eller i API-svar.

Lagringstilstand. Vælg en af tre:

• Everything. Transskriptioner, optagelser og logs gemmes.
• Everything except PII. Indhold gemmes med dine valgte PII-kategorier fjernet, og de rå originaler slettes.
• Basic Attributes Only. Der gemmes ingen transskriptioner, optagelser eller logs, og Get Call returnerer opkaldet uden dem.

Hvis du fravælger lagring, indeholder webhooks stadig transskriptionen og optagelsen, men optagelseslinket udløber 10 minutter efter, at webhooken ankommer. Byg din webhook-modtager, før du skifter.

Update Calls data_storage_setting kan gøre et enkelt opkald strengere, aldrig mindre strengt. Autoriserede dashboardbrugere kan fjerne et opkalds følsomme data eller slette opkaldet, og Delete Call (DELETE /v2/delete-call/{call_id}) gør det samme via API. Begge dele kan ikke fortrydes.

Optagelses- og log-URL'er udløber ikke som standard. Slå Opt In Secure URLs (opt_in_signed_url) til, så bliver hver URL, du anmoder om, signeret og udløber efter 24 timer eller efter en varighed, du selv sætter fra 1 minut til 7 dage.

Hvad fjerner PII-maskering egentlig?

Under Everything except PII registrerer Retell de kategorier, du vælger, efter opkaldet og erstatter hver forekomst med en nummereret pladsholder som [email 1]. De 13 kategorier er personnavn, adresse, e-mail, SSN, pas, kørekort, kreditkort, bankkonto, adgangskode, PIN-kode, medicinsk ID, fødselsdato og kundekontonummer.

Rensningen omfatter mere end transskriptionen: optagelsen (PII-intervaller bliver til et bip), offentlige logs, dynamiske variabler, metadata, opkaldsresuméet og tilpassede analysedata samt argumenter og resultater fra værktøjskald. DTMF-cifre bliver til [PII INFO], når blot én kategori er slået til.

Hvis du vælger phone_number, fjernes kundens nummer fra selve opkaldsposten (from_number ved indgående, to_number ved udgående opkald). Lad den være fravalgt, hvis et system længere nede i kæden matcher på det nummer.

Nogle felter renses aldrig, herunder call_id, agent_id, tidsstempler, status, årsag til afbrydelse, call_successful, user_sentiment, omkostning og tilpassede attributter. For også at fjerne dem skal du bruge Basic Attributes Only eller en opbevaringsperiode.

Adgang er rollebaseret. Member-rollen ser kun renset historik, mens Admins og Developers kan se rå transskriptioner og optagelser.

Hvor hostes dataene, og hvad bør sikkerhedsteamet spørge om?

Retells compliance-dokumentation angiver, at Retell overholder HIPAA og GDPR og er SOC 2 Type 1- og Type 2-certificeret, at Retell opfylder GDPR ved at bruge AWS med et GDPR-kompatibelt databehandlertillæg (Data Processing Addendum), og at Retell i øjeblikket ikke driver tjenester inden for EU. BAA og DPA (med EU's standardkontraktbestemmelser) underskrives selvbetjent uden ekstra gebyr, og certifikater og rapporter findes i Compliance Trust Center.

Den offentlige dokumentation angiver ikke en lagringsregion pr. artefakt og navngiver ikke den underliggende lagringstjeneste, så gå ikke ud fra noget. Spørg Retell skriftligt (support@retellai.com håndterer sikkerhedsgennemgange, leverandørvurderinger og lister over underdatabehandlere), og bekræft dine egne indstillinger:

• Hvor behandles opkaldslyden, og hvor gemmes hvert artefakt i tabellen?
• Hvilke underdatabehandlere har adgang til lyd, transskriptioner og analyser?
• Matcher hver produktionsagents opbevaringsperiode og lagringstilstand vores politik?
• Er sikre URL'er slået til med en udløbstid, vi accepterer?
• Hvilke af vores brugere har Admin- eller Developer-roller og kan se rå data?
• Verificerer vores webhook-modtager signaturer og gemmer det, vi har brug for, før opbevaringsperioden sletter det?

Om kontraktsiden (BAA kontra DPA, hindringer for dataopbevaring, indkøbsfaser) kan du læse hvad virksomhedskøbere skal vide, før de implementerer stemme-AI.

Hvad når dit CRM, og via hvilken vej?

Det afhænger af vejen. Retells indbyggede integrationer med Salesforce, HubSpot, Microsoft Dynamics 365, GoHighLevel og Zoho CRM importerer kontakter (hvert 5. minut pr. august 2026), mapper felter fra analyse efter opkald til kontaktfelter, sender feltændringer tilbage og logger hvert opkald som en aktivitet. En Salesforce Task indeholder for eksempel varighed, resumé, samtale-ID, telefonnumre og årsag til afbrydelse. Udgående synkronisering opdaterer kun eksisterende poster, medmindre du slår Create new contacts in CRM til, og aktivitet logges kun for kontakter, der er importeret fra det forbundne CRM.

Optagelser og fulde transskriptioner når kun CRM'et, når vejen overfører dem, som HubSpot Marketplace-appens opkaldslog eller din egen webhook-skriver gør. Om mekanikken fra trigger til tilbageskrivning kan du læse workflowet fra CRM til stemme-AI; integrationsoversigten viser, hvad der kan forbindes indbygget.

Hvordan danner læsningen før opkaldet og skrivningen efter opkaldet ét testbart loop?

En integration er færdig, når ét opkald læser den rigtige post, før det starter, booker aftalen undervejs og skriver teknikernoten bagefter – alt sammen på den samme post. Retells agentside Workflow modellerer det som én graf. På en linje til feltservice:

1. Læsning før opkaldet. En funktion før opkaldet søger i CRM'et efter {{user_number}} og mapper post-ID'et til en variabel. Indgående opkald venter op til 1 minut på den; udgående opkald tillader 5 minutter, før der ringes op.
2. Booking under opkaldet. Agenten booker med et kalenderværktøj (Cal.com, Calendly eller GoHighLevel-kalendere) eller en tilpasset funktion, der kalder dit planlægningssystems API, som kan verificere X-Retell-Signature-headeren. Booking-ID'et lægges i en variabel.
3. Skrivning efter opkaldet. En funktion efter opkaldet opretter noten: Salesforce-, Dynamics 365- og Zoho-værktøjer opretter noter, Zendesk tilføjer private noter, og alt andet kræver en tilpasset funktion. Den genbruger post-ID'et fra før opkaldet, skriver {{call_summary}} eller et tilpasset felt som access_instructions og kører kun, hvis bookingvariablen findes. Funktioner efter opkaldet stopper efter 5 minutter.

Hvis opslaget mislykkes, springes alle funktioner, der afhænger af det, over, så der skrives ingen note uden et post-ID, og opkaldet gennemføres stadig. Én begrænsning for platformteams: workflowfunktioner konfigureres kun i dashboardet og er ikke en del af det offentlige API (pr. august 2026), så de kommer ikke til at ligge i din infrastructure-as-code.

Test loopet i to omgange:

• Simuleringstest med mocks. Mock alle tilpassede funktioner og kalenderværktøjer. En funktion uden mock kalder sit rigtige endpoint og kan oprette en rigtig booking.
• Ét rigtigt opkald mod en sandbox-post. Foretag et testopkald via web eller telefon, og åbn det i opkaldshistorikken. Funktioner før opkaldet vises under Before call og funktioner efter opkaldet under Call ended med de sendte argumenter og returnerede svar. Testen er kun bestået, hvis bookingen findes, noten er på den samme post, og din modtager har logget én call_analyzed-hændelse for det pågældende call_id.

Den bredere pilotplan finder du i sådan evaluerer du en platform til stemmeagenter, før du går live. Hvordan funktioner før og efter opkaldet fungerer, kan du læse i Retell Workflows.

Tag kortet i brug

Udfyld tabellen pr. agent, og vedhæft sikkerhedssvarene, så dækker én side både din gennemgang, din integrationsplan og dit revisionsspor. Vil du se, hvad Retell udtrækker fra hvert opkald, og hvordan det flyder videre til dine systemer, så start med Retells analyse efter opkald.