AI and security
Secure AI for Heavy Equipment Service Organizations
Adding AI to a service system creates a question that matters more than generated text: what information is the AI allowed to see? A useful feature may need some work-order context. It does not follow that every request should receive everything an organization knows. SERA's security approach controls the path to data before AI is allowed to help: authentication identifies the user, verified membership establishes organization context, backend authorization and resource checks determine what may be used, and only then can a feature assemble task-relevant information.
Security starts before the AI request
Prompt quality is not the security boundary. The backend verifies a bearer token, resolves active organization membership, applies module, role and resource rules where relevant, and scopes sensitive database reads to that resolved organization.
The client does not get to establish authoritative tenant identity simply by sending an organization identifier.
The Voice Work Report shows the boundary in practice
For the current Voice Work Report, the Proxy authenticates the user, resolves membership, checks an allowed role, loads the requested work order for the authenticated organization, verifies its linked machine, and rejects mismatched client organization or machine identifiers.
Supported audio is size/type validated. Raw audio is sent by the Proxy to OpenAI for transcription; it is held in request memory and is not written to Supabase Storage or durable temporary files in this workflow.
AI receives controlled task context, not unrestricted database access
After transcription, the structured-draft flow uses limited work-related context such as transcript, machine brand/model and type where present, work-order type, title and issue description. The draft instructions prohibit inventing parts, labor, travel, diagnosis, costs or prices.
This does not claim anything about an external provider's retention, training or storage practices. It describes SERA's application-side request boundary.
Secrets stay on the server
The Proxy owns the Supabase service-role client and reads AI API keys server-side. Flutter does not call OpenAI directly for Voice Work Report. The client receives capabilities, not backend secrets.
Bounded reads are a useful design principle
Tenant-sensitive operations scope reads to the organization, and some current handlers deliberately bound growing reads. The principle is simple: retrieve what a task needs, not an unlimited organization dataset. Specific limits are implementation details, not blanket guarantees.
Future company knowledge needs the same boundaries
Organization-wide repair-history retrieval is future direction. Its safe pattern is authenticated user → verified membership → authorization → current task context → organization-scoped retrieval of a small relevant authorized set → source-linked suggestion → human evaluation.
It is not a global pool of customer work orders and it is not an entire organization database sent to an AI model.
Useful AI is bounded AI
Security is not a slogan about AI never seeing data. It is a controlled workflow that verifies identity, resolves the organization, validates access, limits context and preserves human review.
Next pages to check
Use AI inside a controlled service workflow
Explore how SERA connects reviewed technician reporting, work orders and organization-scoped operational context.