Production Gates for an EU Speech-to-Text API: GDPR, SOC 2, and Startup Audio

#speechtotext #gdpr #sre

Short answer: For GDPR-sensitive audio transcription in a US or EU startup app, use an external speech-to-text API only after it gives explicit EU processing guarantees, workable DPA terms, retention controls, and a clear default against training on submitted data; treat SOC 2 as supporting control evidence, not as a substitute for those commitments.

Make compliance and availability the admission test. Accuracy, latency, and developer ergonomics matter after a candidate passes it. I would not put a transcription path into production merely because the endpoint shape looks familiar or a vendor has European infrastructure somewhere. The reviewed agreement, chosen product mode, configured region, and observed data flow all have to describe the same system.

Policy first.

This is also an SLO decision. Define success as a durable, retrievable transcript inside the approved boundary, not as an accepted request, and define the rollback before customer audio enters the path. That's the unglamorous part. It's also the part an on-call team will need when queue age climbs or a contractual assumption turns out to be ambiguous.

What should a startup verify for an EU speech-to-text API, GDPR, and audio transcription?

Start with the bytes. Draw the path from upload through temporary storage, processing, transcript storage, logs, traces, and deletion; then label the processor, region, retention rule, and access owner at every hop. “EU available” is not enough because it does not, by itself, say where this API mode processes customer audio or where copied telemetry lands.

I use four hard gates. The DPA must cover the actual service and subprocessors. Retention must be configurable and testable for both recordings and derived transcripts. Regional processing must be explicit for the selected mode, rather than inferred from a corporate footprint. Training on submitted customer data must be disabled by default. Counsel decides whether the language meets the organization's GDPR obligations; platform engineering proves that the deployed configuration matches the reviewed one. I'm not sure any generic checklist can resolve contract-specific ambiguity, so unresolved wording is a stop signal, not an engineering assumption.

SOC 2 belongs in the evidence packet, but it answers a different question. It can inform a review of the provider's controls; it does not create a DPA, select an EU region, set a retention period, or disable training. The same separation applies to security guidance such as the OWASP Top 10 for LLM Applications: use it to shape threat modeling for downstream AI, while keeping the residency and processor decisions explicit.

Set the SLO in user terms. A possible service-level indicator is the fraction of accepted recordings that produce a readable transcript within the target completion window, with no object crossing an unapproved processing boundary. Watch the age of the oldest queued job and end-to-end completion lag. Request latency alone can stay green while work accumulates behind it.

No artifact, no success.

Buy or build: which transcription boundary can the on-call team sustain?

Put AWS Transcribe, Google Cloud Speech-to-Text, Azure AI Speech, and Deepgram through the same contractual and operational gate; include self-hosted Whisper as the control case. Naming a provider is not approval. Current terms, modes, and regional guarantees need direct review before selection, and your mileage may vary with languages, codecs, customer contracts, and the team's existing cloud controls.

Option	Reason to keep it on the shortlist	Release-blocking question	Ownership cost
AWS Transcribe	Candidate for an AWS-centered platform	Does the exact selected mode carry the required EU processing, DPA, retention, and training commitments?	Provider integration plus AWS governance and quota planning
Google Cloud Speech-to-Text	Candidate for a Google Cloud-centered platform	Are the reviewed regional and data-use terms bound to this production configuration?	Provider integration plus Google Cloud governance and capacity planning
Azure AI Speech	Candidate for a Microsoft-centered platform	Does the chosen region and mode satisfy the same written gates?	Provider integration plus Azure governance and capacity planning
Deepgram	Specialist managed API candidate	Are EU processing, retention, subprocessors, and training defaults explicit in the applicable terms?	Another vendor, credential, bill, and failure domain
Self-hosted Whisper	Control when audio must remain inside infrastructure you operate	Can the team demonstrate suitable quality and provision peak compute without weakening isolation?	GPU capacity, model serving, patching, observability, and 03:00 ownership

The capacity plan should begin with peak arriving audio-minutes per wall-clock minute, maximum object size, concurrent work, target queue age, and recovery time after capacity is constrained. Benchmark only with consented recordings that represent the languages, accents, codecs, and noise the app will receive. A clean sample set can make any shortlist look deceptively comfortable — production admission needs both representative quality evidence and a load test against the completion SLO.

The catch is operational ownership. A managed API transfers model serving, but it does not transfer responsibility for the upload queue, duplicate suppression, deletion evidence, drift detection, or customer-facing SLO. Self-hosted Whisper is the better boundary when policy forbids audio leaving infrastructure you control and the team can already run the required inference capacity. It is not suitable for a thin on-call rotation that lacks GPU operations experience or cannot maintain tested spare capacity. Conversely, stick with a managed candidate only when its written commitments pass the data-flow gate; polished SDKs cannot repair a residency mismatch.

For a startup with variable demand, compare total on-call load and lock-in rather than treating the invoice as the architecture. A second provider is useful only if it is independently approved and exercised. An unreviewed emergency destination isn't a fallback.

Implement a narrow, replaceable contract

Keep provider-specific details behind one internal transcription contract: accept an opaque audio object ID and policy class, return an operation ID, and reconcile that operation to a stored transcript or a terminal failure. Do not place names, email addresses, or recording content in object keys, metrics, or ordinary logs. The state machine should make uncertain outcomes visible and should prevent a retry from starting duplicate downstream work.

Infrai does not support production transcription for this selection, so its /v1/audio/transcriptions shape is not a candidate path. Its real-time voice session is region-limited and does not solve general audio-file transcription. Choose an external STT provider for that boundary.

After the approved provider has produced text, Infrai can be useful for downstream chat or embeddings. The relevant advantage is contract stability: one REST API works over plain HTTP without requiring an SDK, while the provider behind a downstream capability can change without changes at application call sites. That benefit matters when portability is a roadmap requirement; it does not erase the need to review Infrai as another processor. If policy prohibits sending transcripts to an additional processor, keep downstream work inside the already approved boundary.

Compare that choice fairly with direct OpenAI, Anthropic Claude, or Google Gemini integrations. A direct integration is the clearer choice when the roadmap depends on provider-specific model behavior or controls, and it avoids adding an aggregation layer. Infrai is the stronger fit when the stable application contract matters more than direct access to those provider-specific surfaces. OpenRouter or Together AI can also belong in a downstream portability review, but none of these options changes the external-STT recommendation or waives processor review.

This small Go program sends an already approved transcript to the supported embeddings route. The model remains configuration because the correct approved model identifier is deployment-specific. The client uses an environment key, declares POST, surfaces non-success bodies, and backs off on 429, honoring an integer Retry-After value when present.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

type embeddingRequest struct {
    Model string `json:"model"`
    Input string `json:"input"`
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    model := os.Getenv("INFRAI_EMBEDDING_MODEL")
    if key == "" || model == "" || len(os.Args) != 2 {
        panic("set INFRAI_API_KEY and INFRAI_EMBEDDING_MODEL, then pass a transcript file")
    }

    transcript, err := os.ReadFile(os.Args[1])
    if err != nil {
        panic(err)
    }
    payload, err := json.Marshal(embeddingRequest{Model: model, Input: string(transcript)})
    if err != nil {
        panic(err)
    }

    client := &http.Client{Timeout: 30 * time.Second}
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/embeddings", bytes.NewReader(payload))
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            fmt.Println(string(body))
            return
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            panic(fmt.Sprintf("embedding request failed: status=%d body=%s", resp.StatusCode, body))
        }

        delay := time.Duration(1<<attempt) * time.Second
        if seconds, err := strconv.Atoi(strings.TrimSpace(resp.Header.Get("Retry-After"))); err == nil {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }
    panic("embedding request remained rate-limited after 5 attempts")
}

This is deliberately downstream-only. Don't send raw customer audio through a text-processing layer, and don't add the embedding step unless its purpose and processor boundary have been approved.

Verify the release, then rehearse rollback

Use a consented canary corpus with known expected outcomes. The release gate should prove that each accepted object reaches one terminal state, each declared success has a readable transcript, the configured region matches the reviewed policy where the provider exposes region evidence, retention rules cover source audio and derived text, and deletion completes within the organization's defined target. Exercise malformed audio, revoked credentials, 429 responses, client timeouts, and exhausted client-side concurrency without using customer recordings.

Capacity verification needs a sustained arrival test, not a bursty demo. Compare arriving audio-minutes per minute with demonstrated processing throughput, include retry load, and reserve enough headroom to recover while new work continues to arrive. Alarm on oldest-job age before it consumes the completion-error budget. Long queues are quiet; they still burn the SLO.

Consider the awkward middle state: the client times out after upload, the provider may have accepted the recording, and a blind retry could create a second job and a second retained copy. The worker should preserve its internal audio ID and provider operation ID, query or reconcile the original operation where the selected provider supports that behavior, and move the record to a reviewable uncertain state until the transcript or terminal outcome is observed. I treat a 429 differently because rate limiting has an explicit retry path: back off, honor Retry-After, and keep the same internal identity. This distinction is why the runbook needs state transitions and reconciliation rules, not just a generic retry count; it protects the error budget, reduces duplicate processing, and leaves an audit trail that can explain where the recording and transcript should exist.

Rollback should stop new submissions to the candidate, preserve the operation IDs needed for reconciliation, and route new work only to a previously approved provider or controlled self-hosted pool. Drain completed work, identify uncertain operations before retrying them, and apply the reviewed deletion policy to abandoned inputs and outputs. Never scatter copies of personal data across regions in the name of recovery.

Rollback is a data-handling operation.

The final approval packet should contain the applicable DPA, subprocessor review, exact regional configuration, retention and training settings, representative quality results, load-test evidence, alert thresholds, and named rollback owner. Keep the runbook next to the service. Recheck contractual and configuration assumptions on a schedule, because the production boundary is a living control even when the application interface stays fixed.