EU Speech-to-Text APIs: A GDPR, Data Residency, and SOC 2 Guide

#speechtotext #gdpr #typescript

Short answer: for a startup transcribing logistics candidate interviews, choose a managed speech-to-text API only after its EU processing path, retention controls, deletion process, subprocessors, and SOC 2 evidence survive a real review; choose self-hosted speech recognition when infrastructure control matters more than operational simplicity. In either case, keep transcription separate from candidate scoring and reject malformed rubric output before it reaches a hiring workflow.

Option	Pick this when	Main trade-off	Proof to collect
Managed API with an EU processing option	The team needs fast integration and can approve the provider's full data path	Less infrastructure work, but more dependency on contractual and technical controls outside the app	Processing regions, retention and deletion behavior, subprocessor list, data-processing terms, current SOC 2 report and scope
Self-hosted open-source speech recognition	The team can operate inference in its chosen EU environment and needs direct control of audio storage and deletion	Stronger infrastructure control, but the team owns capacity, patching, monitoring, and model operations	Deployment inventory, access controls, deletion tests, change records, and operational evidence
Split pipeline	Policy permits a managed transcription step, while scoring and records must stay in the startup's controlled environment	More boundaries to reason about and observe	A field-level data-flow map plus evidence for each boundary

The table is the field guide. Don't begin with model accuracy. Begin with the audio's route: browser upload, temporary object, transcription worker, transcript, scoring worker, audit record, deletion job. One vague arrow can invalidate an otherwise tidy architecture review.

How should a startup choose an EU-compliant speech-to-text API for GDPR data residency?

Treat data residency, GDPR readiness, and SOC 2 evidence as separate checks. An EU region answers a location question. It does not, by itself, explain retention, support access, backups, subprocessors, deletion, or whether customer data is used for another purpose. A SOC 2 report is evidence about controls within a stated system and period; it isn't a substitute for mapping personal data or reviewing processing terms.

Ask every candidate implementation the same questions. Where is audio received, processed, cached, backed up, and inspected? Can retention be disabled or bounded? How is deletion requested, and how will the startup verify it? Which people and services can read raw audio? Which subprocessors touch it? Does the SOC 2 report cover the service actually being evaluated, and can the reviewer inspect exceptions rather than stopping at the report's cover page?

Then test the workflow, not the brochure. Use synthetic audio with a unique marker, run it through a non-production environment, request deletion, and verify every storage location the team controls. For provider-controlled locations, retain the provider's documented commitment and the evidence accepted by legal and security reviewers. I'm not sure any generic checklist can settle the final legal basis for a particular hiring flow; that calls for counsel who can inspect the actual data, countries, notices, and contracts.

Candidate interviews need an extra boundary. A transcript is a lossy representation of speech. Names, addresses, accents, pauses, and domain terms can all affect the downstream record, while a scoring model can turn a small transcription error into a confident rubric value. Keep the original transcript, normalized evidence, rubric result, and human decision as distinct records with distinct access and retention rules. That separation makes correction possible.

Pick a managed EU processing path when speed matters

A managed API fits a small team that wants a narrow integration surface and does not want to schedule speech-recognition capacity. The useful architecture is boring: upload to a controlled temporary store, enqueue a job containing an opaque object identifier, transcribe in the approved region, validate the response, persist only the fields the workflow needs, and trigger deletion according to policy.

The catch is external control. If the provider cannot give precise answers about processing location, retention, deletion, subprocessors, and the scope of its assurance report, the team cannot close its evidence trail. Stick with self-hosting when those answers fall outside the accepted risk boundary, or when audio is not permitted to leave infrastructure the startup directly controls. Operationally, measure queue age, transcription duration, audio duration, response status class, and deletion completion. Logs should carry a correlation ID and object ID, never the interview transcript or a signed download URL. Alert on growing queue age and repeated deletion failures. Fast transcription is nice. Completed deletion is part of correctness. Retries deserve care — an innocent retry can create duplicate transcripts or extend the life of temporary audio. Give each interview an idempotency key inside the application, record the attempt state, and make the worker resume from a known transition rather than blindly replaying the whole pipeline. Timeouts should move work to a reviewable state; they should not silently turn an absent transcript into an empty one.

Pick self-hosted recognition when infrastructure control matters

Open-source Whisper is a general-purpose speech-recognition model that supports multilingual speech recognition, speech translation, and language identification. Running an open model in an EU environment can keep the inference path under the startup's infrastructure controls. It also changes the work. The team now owns model packaging, compute capacity, dependency updates, access control, monitoring, and deletion across its storage and logs.

This option is suitable when that operational responsibility already has an owner and the organization needs direct control of the processing environment. It is not suitable when nobody can maintain inference workers, investigate latency, or document changes. In that case, a reviewed managed service may produce a clearer and more supportable control story.

Your mileage may vary across accents, microphones, warehouse noise, job vocabulary, and language switching. Do not publish a universal accuracy claim from a clean demo clip. Build an evaluation set that represents the permitted hiring workflow, have authorized reviewers create reference transcripts, and compare candidates on the same samples. Record the model or service version with every evaluation so a change can be tested before deployment.

Build a typed transcript-to-rubric boundary in TypeScript

The scoring boundary should accept text, not raw audio. That keeps the speech component replaceable and prevents scoring retries from replaying personal audio. It also gives the team one clean place to enforce structured output correctness, which is the primary decision axis in this logistics hiring example.

Suppose the rubric evaluates whether a dispatcher candidate gave evidence about route replanning, handoff communication, and incident escalation. The scorer may suggest values, but its output does not become an application record until a deterministic validator accepts the exact keys, allowed scores, and evidence strings. Unknown keys fail closed. Missing evidence fails closed too.

type CriterionId = "route_replanning" | "handoff_communication" | "incident_escalation";

type CriterionScore = {
  criterion: CriterionId;
  score: 0 | 1 | 2;
  evidence: string;
};

type RubricResult = {
  interviewId: string;
  criteria: CriterionScore[];
  requiresHumanReview: true;
};

const criterionIds = new Set<CriterionId>([
  "route_replanning",
  "handoff_communication",
  "incident_escalation",
]);

function parseRubricResult(value: unknown, expectedInterviewId: string): RubricResult {
  if (typeof value !== "object" || value === null) throw new Error("rubric_not_object");

  const record = value as Record<string, unknown>;
  const allowedTopLevel = ["interviewId", "criteria", "requiresHumanReview"];
  if (Object.keys(record).some((key) => !allowedTopLevel.includes(key))) {
    throw new Error("rubric_unknown_key");
  }
  if (record.interviewId !== expectedInterviewId) throw new Error("rubric_id_mismatch");
  if (record.requiresHumanReview !== true) throw new Error("human_review_required");
  if (!Array.isArray(record.criteria) || record.criteria.length !== criterionIds.size) {
    throw new Error("rubric_criteria_count");
  }

  const seen = new Set<CriterionId>();
  const criteria = record.criteria.map((item): CriterionScore => {
    if (typeof item !== "object" || item === null) throw new Error("criterion_not_object");
    const candidate = item as Record<string, unknown>;
    const allowedCriterionKeys = ["criterion", "score", "evidence"];
    if (Object.keys(candidate).some((key) => !allowedCriterionKeys.includes(key))) {
      throw new Error("criterion_unknown_key");
    }
    if (typeof candidate.criterion !== "string" || !criterionIds.has(candidate.criterion as CriterionId)) {
      throw new Error("criterion_unknown_id");
    }
    const criterion = candidate.criterion as CriterionId;
    if (seen.has(criterion)) throw new Error("criterion_duplicate");
    seen.add(criterion);
    if (candidate.score !== 0 && candidate.score !== 1 && candidate.score !== 2) {
      throw new Error("criterion_invalid_score");
    }
    if (typeof candidate.evidence !== "string" || candidate.evidence.trim().length === 0) {
      throw new Error("criterion_missing_evidence");
    }
    return { criterion, score: candidate.score, evidence: candidate.evidence.trim() };
  });

  return { interviewId: expectedInterviewId, criteria, requiresHumanReview: true };
}

This validator is deliberately strict. A response with error code criterion_invalid_score goes to a controlled retry or human review queue; it does not get coerced from "2" to 2, and it never defaults to zero. That distinction matters because zero looks like a genuine assessment. An absent or malformed result is a system state.

Diagram the runtime in words: temporary audio store -> transcription worker -> immutable transcript version -> scoring worker -> schema validator -> human review queue -> hiring system. Put a metric and an owner on every arrow. Useful counters include transcription_completed, rubric_validation_failed, human_review_queued, and audio_deletion_verified. Compare validation-failure rate by scorer version before promoting a change, while keeping interview content out of metric labels. OWASP's guidance for applications built with language models is relevant to the scoring half of this pipeline. Treat transcript text as untrusted input, constrain downstream actions, validate model output, and avoid giving generated content unchecked authority over business decisions. A candidate could quote instructions during an interview without intending them as system commands. The transcript must remain data.

Know the limits before selecting an architecture

Neither path proves compliance by architecture alone. A managed EU option still needs contractual and operational review; a self-hosted model still needs disciplined access, retention, security updates, monitoring, and deletion. SOC 2 evidence can inform the review, but the system's actual data flow is the unit that must make sense.

Structured validation also cannot prove that a score is fair, accurate, or appropriate. It proves that the payload has the required shape and values. Keep a human reviewer in the decision path, provide the transcript evidence behind each rubric score, support corrections, and evaluate transcription and scoring changes separately. For a startup, that may feel slower. It is much easier to debug than one opaque audio-to-decision call.

No single option wins every time.