AI challenge

We're worried about security or privacy

Which data are we actually sending to which model? Can users see each other's data? What do we log? Where are the secrets? If you can't answer those questions convincingly, it's time to take a proper look at the technical situation.

Does this sound familiar?

Security questions often only come up seriously when an experiment moves towards production or sensitive data.

  1. Nobody knows exactly which data goes to the model

    Prompts, context and uploads are assembled in several places in the application.

  2. Roles and permissions feel fragile

    It's hard to demonstrate that users can only reach their own data.

  3. Secrets and external services grew organically

    API keys and vendors were added whenever they were needed.

  4. Logging may contain sensitive content

    Debugging information may expose more than is desirable.

Where do you want to be?

You want to be able to explain technically where data goes and who may do what, so you don't have to hope sensitive data is handled well.

Clear data flows

You know which data stays internal and which external services process it.

Control over access

Authentication, authorisation and tenant isolation are set up deliberately.

Concrete risk priorities

You know which problems are truly urgent and which risks are acceptable.

Why does this happen?

AI adds new data flows and external dependencies to ordinary software problems around security and privacy.

See how we approach this

Data moves through more systems

Model providers, vector stores, observability tools and integrations can all be part of the same flow.

AI input is less predictable

Users can provide unexpected content or try to influence system behaviour.

The underlying software remains decisive

Poor authorisation isn't fixed by choosing a safer language model.

Why 9to5 for this?

For us, AI security starts with ordinary software engineering, not with prompts: understanding data flows, limiting access, managing secrets and containing errors.

View cases

End-to-end view

From user and database to model provider and logging.

Practical prioritisation

Not every theoretical risk gets the same urgency.

Able to build the fix too

The advice doesn't have to go to another technical party afterwards.

What else fits your situation?