diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3163c4b0d4..932599c70a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,6 +6,7 @@ Below summarizes the processes that we follow.
 
 ## Topics
 
+* [LLM ("AI") Policy](#llm-ai-policy)
 * [Reporting Issues](#reporting-issues)
 * [Working On Issues](#working-on-issues)
 * [Contributing to Podman](#contributing-to-podman)
@@ -13,6 +14,11 @@ Below summarizes the processes that we follow.
 * [Submitting Pull Requests](#submitting-pull-requests)
 * [Communications](#communications)
 
+## LLM ("AI") Policy
+
+If your contribution is aided by LLMs or other AI tools, please read the [LLM Policy](LLM_POLICY.md).
+This includes comments, issues, PRs and any other interactions with the Podman team.
+
 ## Reporting Issues
 
 Before reporting an issue, check our backlog of [open issues](https://github.com/containers/podman/issues) to see if someone else has already reported it.
diff --git a/LLM_POLICY.md b/LLM_POLICY.md
new file mode 100644
index 0000000000..61d4fe1e1b
--- /dev/null
+++ b/LLM_POLICY.md
@@ -0,0 +1,81 @@
+![PODMAN logo](https://raw.githubusercontent.com/containers/common/main/logos/podman-logo-full-vert.png)
+# Podman LLM (AI) Development Policy
+
+This document is based on [Jellyfin LLM Policy](https://jellyfin.org/docs/general/contributing/llm-policies/)
+and licensed under [CC-BY-ND-4.0](http://creativecommons.org/licenses/by-nd/4.0/).
+
+LLMs such as Claude and ChatGPT are powerful development tools. They can
+help both experienced and new developers. However, they also introduce risks.
+
+Podman has always prioritized code quality (readability, simplicity, and conciseness)
+and friendly communication. Our small team maintains these standards manually. As LLM
+usage grows within the Podman community, this policy clarifies our expectations for
+contributions and communication across all official projects and spaces.
+
+## No LLM-Generated Direct Communication
+
+LLM output must **not** be used verbatim in:
+
+* Issues or comments
+* Pull request bodies, comments, or commit messages.
+* Forum or chat posts
+* Security and vulnerability reports
+
+All communication must be written in your own words. You must understand what you are submitting.
+
+LLM-written content is often long, impersonal, and error-prone. As a small team with limited
+resources, we are unable to spend time reviewing unclear submissions or responding to impersonal
+comments.
+
+* Exception: If you use an LLM to translate your thoughts into English, clearly state this
+  (e.g., “Translated with an LLM from MyLanguage”).
+* Exception: The LLM-based bot can be configured by the maintainers to review the PRs
+  and suggest changes. These changes are only suggestions and might be wrong. It’s up
+  to the contributor and maintainer to decide whether the particular suggestion makes sense.
+
+Repeated violations may result in the closure or deletion of the submission or in a permanent ban from Podman projects.
+
+## LLM Code Contributions
+
+LLMs may assist with code, but you are fully responsible for what you submit.
+
+### Requirements
+
+* Follow all guidelines in [CONTRIBUTING.md](CONTRIBUTING.md).
+* Keep changes concise and focused.
+* Match existing formatting and quality standards.
+* Remove unnecessary comments, poor structure, whitespace issues, and editor/LLM metadata files (e.g., .claude configs).
+* The code must build, run, and pass tests before review begins.
+* Explicitly test the functionality you modify.
+
+### Understanding and Ownership
+
+You must:
+* Review all generated code.
+* Clearly explain (in your own words) what the change does and why in both the PR body and commit message.
+* Be able to discuss and justify your changes during review.
+
+Submitting “vibe-coded” or poorly understood changes will result in rejection after a few attempts to correct them.
+
+### Handling Review Feedback
+
+Do not paste reviewer feedback into an LLM and resubmit whatever it generates.
+
+Please engage in the review process by:
+* Responding thoughtfully to feedback using your own words.
+* Making minimal, targeted changes to address comments.
+* Understanding the implementation of required changes.
+
+### Final Discretion
+
+Maintainers have final discretion. PRs that are too large, overly complex, poorly structured,
+or difficult to review may be rejected after a few attempts to correct them — regardless
+of whether LLMs were used.
+
+Violations may result in the closure or deletion of the submission, or in a permanent ban from Podman projects.
+
+## The Golden Rule
+Do not prompt an LLM vaguely. Do not commit the LLM results unchanged. And do not submit them as-is.
+
+Using LLMs as a tool is completely fine. Using them as a replacement for understanding,
+responsibility, and craftsmanship is not.