Due to the inherent risks associated with using dynamic languages (e.g. Python, Ruby) carelessly, what (if any) standards should be imposed on production code written in these languages?
Your question contains two contradictory elements:
that someone would use the language carelessly, and
that they would follow standards for the production code.
Any programmer that is part of a team that has standards for production code should not use a language, dynamic or not, carelessly. There is a lot of experience with writing code in dynamic language, starting with Lisp many, many years before Java was even thought of.
While non-dynamic languages can catch some errors at compile time, they would not catch mistakes like erroneous conversion from SI to English units, etc. As far as I know (and I would love to be proven wrong...) there does not exist any study that has shown that using dynamic languages to write programs leads to more errors.
Many programmers writing on this, and other forums, express strong opinions one way or another but I suspect (no proof, sorry...) that there is a lot more variation in programmer's skills and proficiency in using good tests than there is coming from the use of language X over language Y. (with the possible exception of Ada...)
Coding standards should be a simple as possible and hopefully restricted to avoiding language features and idioms which are known to be problematic or broken.
Too many rules in program standards can lead programmers to code sub-optimal and unreadable code because the best solution has been declared "bad" in the standards doc.
What dynamic languages really require are higher testing standards. As there are more run time errors possible, and, the forgiving nature of the languages means simple coding errors can cause weird behavior in seemingly unrelated components. You really need a good set of unit tests for every single component, plus a comprehensive set of integration tests which should be run every-time any piece of code has changed.
Not so much a coding standard as a good practice, I would say aggressive testing.
As you said, there are inherent risks with dynamic languages. Issues that would never even exist in a static language can and will crop up in poorly designed or written code in a dynamic language. Applying comprehensive, well-written unit tests as a part of your process will help ensure your code is correct and error free.
What "inherent risks" are you thinking of? I can't think of any run-time error that can occur in Python or Ruby that can't occur in C# or Java. Null pointer exceptions, missing method exceptions, and type conversion errors are all possible in C# and Java. In Java, we add back all the missing dynamic behavior through Spring and other packages layered on reflection. This enables all the run-time errors inherent in dynamically typed languages, except that to fix them you have to sift through seventeen layers of XML configuration files.
Connecting strongly typed languages to the untyped HTTP protocol, and the differently-typed SQL database in any reasonable way requires type conversions that cannot be validated at compile time. I don't believe that dynamically typed languages require special care. No matter the language, delivering reliable code will require extensive testing.