What is an AI ethics in security meetup?

A session that brings AI security practitioners and AI ethics or responsible-AI practitioners into the same room, on the basis that problems like prompt injection, model access control and data provenance have both a technical and a human dimension that the two groups usually handle separately.

Do I need to be a security professional to attend?

No. These sessions work best with a mix — engineers, policy and compliance people, legal, and product owners. The shared vocabulary that develops between those groups is most of the value.

How many people do I need to start one?

Ten people who work on the subject is a strong first meeting. What you actually need is a room, a date, and one prepared talk; the rest follows from attendees bringing colleagues.

Should vendors be allowed to present?

Sponsors can fund a venue and be named, but giving them a speaking slot reliably drives away the practitioners you most want. Keep the talks practitioner-only and state the rule publicly.

AI Ethics in Security Meetups: What They Cover and How to Ru

There is a specific kind of room worth building: one where the people responsible for securing AI systems and the people responsible for the ethics of those systems are in the same conversation. They are usually not. Security reports through the CISO, ethics through legal, policy or a responsible-AI function, and the two meet at a review gate when it is far too late to change anything.

Meetups are unusually good at fixing that, because attendance is voluntary and nobody is defending a budget.

Why the two topics belong in one room

The overlap is larger than either side tends to assume. Prompt injection is a security problem with an ethics tail: the exploit is technical, the harm lands on a user. Model access control is an ethics problem with a security tail: who is allowed to query what, and what does the audit trail have to prove afterwards. Data provenance sits squarely in both — the security team wants to know what is in the training set because of leakage, the ethics team because of consent.

Where these groups meet regularly, the useful outcome is rarely agreement. It is vocabulary. Security people learn that "acceptable risk" has a different meaning to someone thinking about disparate impact, and ethics people learn why a control that cannot be monitored is not a control.

Topics that reliably fill a session

Red-teaming an agent, live. Bring a system with tool access and try to make it do something it should not. The ethics questions surface on their own the moment it works.
Access control for model endpoints. Who can call what, with which data, and how you would prove it after an incident.
Incident response for AI-specific failures. The playbook for a model producing harmful output is not the playbook for a breach, and most organisations have only written the second one.
Data provenance and retention. What went into the system, what you can delete, and what happens to embeddings when someone exercises a deletion right.
Monitoring that would actually catch drift. Not the dashboard nobody opens — what threshold pages someone at 3 a.m.
Vendor assessment. The questions worth asking a model provider, and which answers should end the conversation.

A format that works

Two hours, on a weekday evening, roughly in thirds.

First third: one prepared talk, twenty minutes, hard stop. A practitioner describing something they built, broke or fixed. Not a vendor overview. The hard stop matters more than the content — a talk allowed to run long eats the part of the evening people came for.

Second third: a live exercise. Put a system on the screen and attack it, or walk a real incident timeline and stop at each decision point to ask what should have happened. People remember what they watched go wrong far better than what they were told.

Final third: unstructured. Do not fill it. This is where somebody mentions the thing they are quietly worried about at work, and where the group's actual value gets created.

Ground rules worth stating out loud

Say at the start that nothing attributed leaves the room. Security practitioners cannot discuss real incidents otherwise, and without real incidents the session becomes a reading group.

Ban vendor pitches explicitly, including from sponsors. A sponsor can buy pizza and say their name; they cannot have a slot. Groups that blur this die quickly, and the people you most want in the room are the first to stop coming.

Frameworks — NIST AI RMF 1.0, ISO/IEC 42001, the EU AI Act — are useful as shared reference points, but a session that only compares frameworks will not hold a room twice. Use them to structure a specific decision, not as the subject.

Starting one where you are

You need three things: a room, a date, and one prepared talk. Not a committee, not a sponsor, not a website. Ten people who work on this is a good first meeting; the second one is easier because the first attendees bring colleagues.

If you are unsure whether there is an audience nearby, look at what already exists in your area first — an AI security group, an OWASP chapter, a responsible-AI meetup — and consider running a joint session rather than a competing one.

Browse AI communities by city to see what is already running near you, or check upcoming AI meetups. Listing an event is free.

AI Ethics in Security Meetups: What They Cover and How to Run One