At VTEX, the Information Security team is the source of truth for a huge range of recurring questions. Employees ask things like “what’s VTEX’s password policy?”, “am I allowed to use this tool?” or “how do I report a phishing email?” Clients running a risk assessment on VTEX ask a different but equally repetitive set: “does VTEX have an access management policy?”, “what’s your incident response process?” or “can we run our own pentest on the platform?”.

These are not new questions. The answers already exist — in internal guidelines, in the Global Information Security Policy, and, for a large share of client questions, in certifications and attestations VTEX already holds: pentest reports, SOC 2, ISO 27001, PCI DSS. There’s even a standing procedure (PR.SI.004 — Risk Assessment for Clients via Security FAQ) that formalizes this: when a client opens a ticket for a risk assessment, the first move is to point them to the Security FAQ on the VTEX Trust Center, built specifically from the questions clients’ own risk assessment questionnaires ask most. Most of the time, the certificate we can already hand over answers the question faster and more authoritatively than a custom-written reply would.

Before ISA, that gap showed up in a few consistent ways:

• No single channel. Employees didn’t have one obvious place to ask. Questions landed in random Slack DMs, scattered channels, or tickets — each one requiring a human to triage before anyone even got to the actual answer.

• Tickets for questions that already had answers. Every client risk-assessment request came in as a ticket, even when an existing certification already covered it.

• The connection wasn’t obvious. A pentest attestation VTEX had already produced, or a SOC 2 report already on file, often was the answer — but whoever was asking didn’t always know to look there first, or didn’t have it at hand at the moment a client pushed back.

We needed something that could sit in front of all of that: answer the 80% of questions that are genuine repeats, point confidently at the certificate or policy that already settles it, and only escalate to a ticket what’s actually new.

That’s ISA — the Information Security Assistant. It lives at isa.vtex.systems, gated behind Google OAuth restricted to @vtex.com accounts and reachable only from the corporate network via Netskope. Open the chat, pick a language, ask a question the way you’d ask a colleague, and get a streamed answer with the source it came from attached.

How does it answer a question? When a message comes in, ISA detects two things from the text alone: which platform the question is about (VTEX or Weni — defaulting to VTEX when it’s ambiguous) and which language it was written in (Portuguese, English, or Spanish). It then pulls context in parallel from three sources:

That curation step matters: rather than dumping entire policy documents into the model’s context and hoping for the best, a first Gemini call extracts just the passages relevant to the specific question, and a second call generates the answer from that narrowed context. No vector database, no embeddings pipeline — just two focused model calls, which keeps the architecture (and the cost) predictable.

Directions for real-world reference: This is the part that maps directly to what the Information Security team already does for client risk assessments: a large share of “is VTEX compliant with X?” or “can I share our security posture with this client?” questions aren’t really open questions — they’re already answered by a report, policy, or attestation that exists today. ISA’s knowledge base includes exactly that layer: the FAQ built from real risk-assessment questionnaires, the guidelines that back it, and pointers to where the fuller documentation (certifications, pentest attestations) lives. Instead of someone needing to remember that a pentest report was already shared, or that SOC 2 already covers a given control, ISA surfaces the right document the moment the question is asked — the exact same first move PR.SI.004 already prescribes for client tickets, just available instantly and to anyone, not only to whoever is on ticket duty that day.

Guardrails: A few things are enforced regardless of how a question is phrased:

• Any answer drawing on internal policy carries a confidentiality disclaimer.

• If nothing in the knowledge base covers a question, ISA says so plainly and points to opening a ticket — it does not speculate or guess.

• It only knows about general policies and guidelines, not client-specific contracts, account configurations, or vulnerabilities. Those still go to the team that owns them.

• Best practices for using ISA are described here.

The point of putting an assistant on the front line isn’t to replace the security team’s judgment on anything that’s actually novel or risky. It’s to stop spending that judgment on the same ten questions every week. Every routine question ISA resolves on the spot, such as a ticket that never needed a human triage step, and a certificate or policy that gets reused instead of re-explained from scratch.